HELP - NAV 2009 web services (time data type)

blusky75

We've exposed several service-related pages as web services. In particular, Page 6005 (Resource Allocations). I've written a C# application to consume those web services. Everything works great, however...

I noticed that the Start Time and Finish Fime fields returned by this page web service when executing a readMultiple() command are off by one hour. For example, if a resource is allocated between 9:00 AM to 10:00 AM, the web service returns 10:00 to 11:00 AM. I havent yet determined if this is an issue isolated with Page 6005 or this affecting all page-based web services where time data types are involved.

The role tailored client, classic client, and web service C# application are all installed on the same machine which is configured for Eastern timezone. The machine running the NAV 2009 web services is also configured for EST. Both the role tailored and classic client are reporting back the correct time (9:00 AM to 10:00 AM). Only the c# application is getting incorrect times from the webservice.

I haven't found any relevant parameters in the customsettings.config that could possibly affect this.

Has anyone come across this and if so, how do I fix this?

blusky75

A brief update. The problem does not appear to be limited to a particular page.

Step 1)
I wrote a simple code unit with the following function to return the current system time. I then published this CU as a webservice. C/AL in the function is as follows:

currenttime := TIME;

Step 2)
I wrote a simple c# console app that displays both the current system time, and the datetime returned by the above web service. This is what was displayed:

Client System Date is: 15:51:30.9645704, NAV Service time is 16:51:30.9479682
Press a key to continue

The console application was run on the same server running the webservice. Under this scenario, there should be no reason at all why there would be a 1 hour difference.

Does anyone have any ideas or have I discovered a bug?

blusky75

Even stranger is the following:

Create a web service method that returns the nav server time as a string. The correct time gets returned. Whatever the problem is, it appears to occur after the NAV time is serialized to a .NET datetime datatype when the soap call is returned. Something with the web services tier is adding that extra hour to times.

Any ideas anyone?

freddy.dk

What happens if you change your function to return a DateTime instead and in your function set the return value to CurrentDateTime ?

In your C# program you should then call your function and get the value into a

DateTime dt = service.fun();
dt = dt.ToLocalTime();
MessageBox.Show(dt.ToString());

My assumption is, that it works.

So why is this?

The issue is, that .net doesn't have the concept of a time - it has DateTime and it has TimeSpan.
We expose dates, times and datetimes as DateTime and a time becomes the timeofday on January 1st year 0001.
.net then adjusts for daylight savings time and then you get your one hour difference.

In fact if you change your computer date to January 1st - you will see that you get the right time.

So why don't we just return time's with current date instead of January 1st 0001 - well, that would be just as wrong, if you store that value anywhere.

We have done a lot of work in SP1 around Time to allow clients to connect to the service tier from multiple timezones (as you can imagine that isn't simple) - and in SP1 your time will always be returned in Utc - meaning that your time would be off by far more than 1 hour if you live in the US, but you can call dt.ToLocalTime() to get your local time.

My advice to you - if at all possible, use DateTime - especially when going through web services.

Hope that helps.

blusky75

Thank you for the update.

I agree with you on using datetime as much as possible (since it's timezone friendly), but in the cases such as the Service functional area, this is not possible without modding.

That said, until NAV 2009 SP1 is released, what is the best recommended approach for handling fields where where a "time" data type is used (and not "datetime"). The service functional area uses the time data type in several areas (in particular, table 6005 captures capture starting and finishing times with via time data types).

I do not agree that the starting and finishing times stored in the resource allocations table should be based on January 1st 0001. There is a field labeled 'Allocation Date' that should be used in tandem with the start and finish times. Example, if the allocation date is April 25 2009, shouldn't the start and finish times be based on that date and not 01/01/0001?

I am reading your reply correctly, does this mean that any page or codeunit web service that utilizes a time data type fundamentally broken?

I'll try working around this by perhaps calculating the actual time by adding the allocation date to the starting / finishing datetime returned by the web service. I'm hoping that this will produce the correct time, if it is at least a stop-gap.

freddy.dk

I do not agree that the starting and finishing times stored in the resource allocations table should be based on January 1st 0001. There is a field labeled 'Allocation Date' that should be used in tandem with the start and finish times. Example, if the allocation date is April 25 2009, shouldn't the start and finish times be based on that date and not 01/01/0001?

I am not suggesting January 1st 0001 - that's just what currently happens.

A workaround could be to create another field on the page, which could contain a variable (non-time) in AfterGetRecord - and then read that through Web Services? instead of the Time field - or maybe create a shadow field in the database which when changed affects the time field and is affected by the time field.

blusky75

Thank you for the tip!

I'm thinking it may also be possible to correct the times from the client as well.
.NET 2.0+ offers a Timezone.CurrentTimeZone.IsDaylightSavingTime(DateTimeObject) function as well. DateTimeObject can be calculated by adding the starting time's time-of-day to the allocation date.

I haven't used the IsDaylightSavingTime function before, but I'm thinking this can be used to accurately adjust Nav times from the web service consumer.

Should the MSDN NAV 2009 web services documentation be updated? It seems the NAV time data type is something that the .NET community should be very cautious of.

Again, thank you for all the help Freddy,

Steve

freddy.dk

Note that any fix you do on the client to solve this problem might cause the problem to be double fixed when you get SP1 - just a warning.

blusky75

freddy.dk, thanks for the update

Wouldn't your previous suggested server-side fixes however be also affected by SP1 (i.e. double-fixing the times)?

Is there a C/SIDE function that will tell me which service pack is installed? Determining the installed service pack programatically would guarantee that any time conversions will work (both pre- and post- SP1).

ABS_Matt

If You Are Running Microsoft Dynamics NAV 2009 R2 You Can Specify The Time Zone Used.

By Changing The WebServicesDefaultTimeZone Setting in CustomSettings.config file.

View Example