Hi all,
I wondered if anyone experienced the following issue in the past and if so maybe someone knows how to solve it.
I'm calling a NAV web service from a .NET application. The NAV web service is a page broadcasted together with a codeunit (they have the same web service name but the codeunit is not "published").
Sending data to the web service runs fine but we noticed that datetime fields are not stored correctly in NAV. In fact the time value displays 2 hours later than the value sent form the .NET application.
I know about the "ServicesDefaultTimeZone" in the CustomSettings.config and put that to "Server Time Zone". So now NAV receive CEST (UTC + 2) from the external application and should store UTC in the SQL database. The RTC client should then also show UTC + 2 (See
http://blogs.msdn.com/b/nav/archive/2011/01/11/time-zones-usage-in-microsoft-dynamics-nav-web-services.aspx).
I tried everything but the NAV 2013 web service is still seeing the time I send as UTC.
I restarted the service, restarted the server, modified all other NAV services on the same server (including 2009 R2)...unfortunately nothing works.
Monitoring the outgoing web service call in my .NET application learned that it is sending the correct times.
I also tried it on my local PC and I get the same result. Tests on NAV 2009 R2 showed that it is actually working on that version.
Anyone an idea ? Or does anyone know if this is a known bug in NAV 2013 ?
Thank you very much in advance.
Kind regards,
Tom T.
Comments
The ServicesDefaultTimeZone parameter fixed this issue when I encountered it, but only for one timezone. It becomes more complicated when you have users in different timezones connected to the same database :?
I suggest that you use the management console instead of manually editing the CustomSettings.config file, especially if you're not using the default instance.
My config file contains this line:
<add key="ServicesDefaultTimeZone" value="Server Time Zone" />
And of course this modification requires a restart of the NAV service.
Best regards,
François
I think your best option is to store your dates as Unix Timestamps, which are just integers.