Calculating the Local Time from UTC

ta5

Hi

Does anybody have an elegant way to calculate the local date time from an UTC specified date time.

Example:
Input: 2008-05-20T10:00:00Z
Output:2008-05-20T12:00

The emphasis is on the word "elegant". I know it is easy if you know the start date and the end date of the daylight saving and if you know the timezone you are in. But this information must be either be setup in navision or read from elsewhere, for example the windows registry.

The opposite is quite easy, using the Format statement with parameter "9"
http://www.mibuso.com/forum/viewtopic.php?t=25228

Any ideas will be appreciated. Thanks.
Thomas

[edit]
Btw, this looks strange to me:My computer is set to GMT+1 (Amsterdam, Berlin, Rome,etc)

myDateTime := CREATEDATETIME(010108d,10t)
Format(myDatetime,0,9) ==> 2008-01-01T08:00:00Z

myDateTime := CREATEDATETIME(010508d,10t)
Format(myDatetime,0,9) ==> 2008-05-05T08:00:00Z

Actually I expected in the first date (january) the time part would be 09:00 ](*,)

kine

No, it is not working with the timezone for the date you are converting. It is working with actual timezone of your computer - it means that it is correct.

ta5

kine wrote:

No, it is not working with the timezone for the date you are converting. It is working with actual timezone of your computer - it means that it is correct.

Sorry, I didn't get that :?
I thought a daylight saving date has another difference to UTC than a normal date?

kine

Yes, it has, but it depends on your system time, not on the date you are working with...

ta5

kine wrote:

Yes, it has, but it depends on your system time, not on the date you are working with...

Isn't it quite useless like this?

ara3n

ta5 wrote:

kine wrote:

Yes, it has, but it depends on your system time, not on the date you are working with...

Isn't it quite useless like this?

In addition it's not working properly with 4.x and is fixed in 5.x.

I find it useful when we creating xml file.

kine

ta5 wrote:

kine wrote:

Yes, it has, but it depends on your system time, not on the date you are working with...

Isn't it quite useless like this?

No, it isn't. It is focused on data reading and entering. It means that you are entering the time in your local time which is right now. If you look at it from another timezone, you will see it recalculated into your timezone. I never saw application taking into account TimeZone active at the date you are entering... If you are entering the 10:00:00 for some day right now, it means that you want to store 11:00:00 (or 9:00:00) when Daylight saving is active/inactive. You need to count with that, sometime is better to store just date and just time into two separate fields because this timezone recalculations...

Mogens

You can find the Windows Time Zone offset from GTM by reading in the system Register:


CREATE(WSH);

v := WSH.RegRead('HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\TimeZoneInformation\ActiveTimeBias');

EVALUATE(Minutes,FORMAT(v));

---

where WSH is Automation 'Windows Script Host Object Model'.WshShell
v is a datatype Variant

ta5

Thanks for all inputs on this.
I actually need both function (to and from UTC) for a xml interface. In the xml messages there are a lot of dates (also from the past and from the future) and they all have to be expressed as UTC.
So if I get it right there is no way arround to find out whether a given date to convert is in daylight saving or not and then calculate the UTC.

Thomas

kine

ta5 wrote:

Thanks for all inputs on this.
I actually need both function (to and from UTC) for a xml interface. In the xml messages there are a lot of dates (also from the past and from the future) and they all have to be expressed as UTC.
So if I get it right there is no way arround to find out whether a given date to convert is in daylight saving or not and then calculate the UTC.

Thomas

You do not need that. If you find your actual timezone, and you save the time shifted by this, it will be again saved as UTC... you only need that if you want to know explicitly if the date is in daylight saving zone or not. But this can be done in another way (the limit dates are given).

ta5

Well, I'm still a bit confused, but let me explain in detail what I want to achieve:

We have a queue table, containing message headers. This table contains some datetime fields The headers are transformed to a xml file by nas using dom The date time in the xml file must be in utc As far as i understand, the datetime read from the table by the nas is transparently converted to local time which means nas does not know the utc value When nas is writing the xml file then the time must be converted to to utc

kine

No, it is not working that... it is transparent and it just depends on which tool you use to look at the data.

The standard format of Date and Time in XML is that the value is in UTC or has the time zone information at the end. If you use XMLPort in NAV, it will automatically take this UTC and will work with it as with UTC time, but if you look at the value, you will see it in your local time. But internally it is still UTC... And if you export the value through XMLPort, it will be exported in UTC. It means - internally it is still same time, but if you look at it before import into NAV, in NAV and after you export it from NAV, you can see different values because you will see it in UTRC or in local time depending if you are viewing it as text (e.g. in some XML editor) or as DateTime (in NAV). But you need to handle it as XML format, not as text with some transformations etc...

ta5

I use ms xml-dom. Is this a problem? Btw: I test the xml's with notepad.

ara3n

Hello has anybody implemented DateTime conversion to UTC as of a certain date?

For example

03/01/08 8:31:28 PM Eastern Time needs to be converted to UTC - 4 hours.


Right now Format (0,9) will translate this to - 5 hours.

ta5

ara3n wrote:

Hello has anybody implemented DateTime conversion to UTC as of a certain date?

For example

03/01/08 8:31:28 PM Eastern Time needs to be converted to UTC - 4 hours.


Right now Format (0,9) will translate this to - 5 hours.

As written earlier in this thread, Format(0,9) is not as good as it seems because it does not check the formated data, it does only check the system date...

You can make a setup field with the offset from UTC during winter time and from UTC during summer time. A user defined function then can check whether a given date is in daylight saving time or not (daylight saving starts on last sunday in march for example, possibly this is also in setup). Then add/subtract the offset from the initial time value.

What I first tried was to read the registry, but I needed wsh for this (customer was not happy about this fact). I guess this would be the only proper solution.

Thomas

ara3n

Format(0,9) doesn't work in 4.0 x version. :bug:


I wrote my own implementation.


The issue with US Eastern Time Zoneis that before 2006. Daylight saving time was in April and now it's second Sunday in March .

the ending has also changed from last Sunday in October to first Sunday in November.