I came across an issue that I hadn’t fully considered while investigating something else. It has to do with the Time Zone context that Web Services execute in.
I have a SOAP service configured with the default time zone setting of UTC. What I noticed was that when CURRENTDATETIME is executed while running code from a web service call the value returned is the current date and time value for the time zone of the server the service is running on. However, the value appears to be getting stored in the database as though that value actually is the UTC datetime and no offset is applied.
So for example:
- Server is setup as Eastern Time (Canada)
- Web Service default time zone is UTC
- Code executed from Web Service calls function CURRENTDATETIME (returns for example 2017/01/10 16:30:00) and saves it as a field in a table
- Value is saved as if it represented UTC time, not Eastern Time.
- Viewing the value later from a client in Eastern Time will display 2017/01/10 21:30:00 (UTC Value + offset for TimeZone)
Obviously, for fields in which the datetime is required to be accurate this is not very useful.
I think this could be resolved for this case by changing the default service time zone to eastern time (or I believe there is a setting for Server Time Zone) but I haven’t tested it yet. Then my concern is with datetime values passed as parameters through web services. Currently all DateTime parameters and values are converted to UTC before sending through the web service. With the default at UTC it’s easy to know what that represents but if we change the service default then all the calling programs would need to changed to convert the value Eastern Time, no?
Is there a best practice for handling time zones issues like this? For this particular service there are users calling these functions who are in different time zones.
This is happening with a Nav2016 installation but I imagine that this behaviour would apply more broadly.