DateAndTime primitiveSystemOffset = broken

[Sam De Block]

Hi,
The following sample illustrates a broken primitiveSystemOffset when DST is in action. I live in GMT+1 timezone.

Code: Select all

DateAndTime year: 2008 month: 2 day: 14 hour: 13 minute: 30 second: 0 
    displays 2008-02-14T13:30:00+01:00
DateAndTime year: 2008 month: 4 day: 14 hour: 13 minute: 30 second: 0
    displays 2008-04-14T13:30:00+01:00


This is wrong. On February 14, DST is not action so system offset is correct with +01:00.
However, on April 14th, DST is in action so system offset is WRONG, it should be +02:00.

Someone here once suggested using the following code for primitiveSystemOffset

Code: Select all

primitiveSystemOffset
   "Answer an <Integer> representing the westward displacement of system local time
    from UTC in seconds.  The value can be betwen 0 and 86400 minutes."

   | daylightSavingInAction baseOffset dstOffset timezoneInformation |

   timezoneInformation := OSTimeZoneInformation calloc: 1.
   daylightSavingInAction := timezoneInformation getTimeZoneInformation.

   baseOffset := timezoneInformation Bias.
   dstOffset := timezoneInformation DaylightBias.

   timezoneInformation free.

   ^(baseOffset + (daylightSavingInAction = PlatformConstants::TimeZoneIdDaylight ifTrue: [
      dstOffset]
   ifFalse: [0])) * 60


While this is nice, it just moves the problem, because now I get the following result

Code: Select all

DateAndTime year: 2008 month: 2 day: 14 hour: 13 minute: 30 second: 0 
  displays: 2008-02-14T13:30:00+02:00
DateAndTime year: 2008 month: 4 day: 14 hour: 13 minute: 30 second: 0
   displays: 2008-04-14T13:30:00+02:00


So my offset for April 14 is correct, but the offset for February 14 is wrong.

When using the following java code:

Code: Select all

    SimpleDateFormat format = new SimpleDateFormat("yyyy-MM-dd'T'HH:mm:ss");
    Date date = format.parse("2008-02-14T13:30:00");
    Date date2 = format.parse("2008-04-14T13:30:00");
    System.out.println(date);
    System.out.println(date2);

Gives the following output:
Thu Feb 14 13:30:00 CET 2008
Mon Apr 14 13:30:00 CEST 2008


Any suggestions on how to fix this?

[marten]

Yes, you are right. The class methods (for creating DateAndTime instances) always
assume the current system time zone offset when creating instances of that class -
this seems to be simple wrong ...

Perhaps for your own needs you may consider

Code: Select all

         European Economic Community:
         Begin DST: Sunday March (31 - (5*y/4 + 4) mod 7) at 1h U.T.
         End DST: Sunday October (31 - (5*y/4 + 1) mod 7) at 1h U.T.
         Since 1996, valid through 2099€


[Sam De Block]

Is there any official response on this?

[tc]

Hello,

I tried the same thing, I am on the east coast of the US and inspected the following:

Code: Select all

DateAndTime year: 2008 month: 4 day: 23 hour: 10 minute: 18 second: 0

. . . which produced:

2008-04-23T10:18:00-05:00

. . . checking the world time web page at:

http://www.timeanddate.com/worldclock/

. . . the actual time is:

Current UTC (or GMT/Zulu)-time used:
Wednesday, April 23, 2008 at 14:18:08

. . . meaning the above should have been:

2008-04-23T10:18:00-04:00

. . . I looked back through problem reports sent in by users and found this issue and it said the time settings on the OS need to be correct. I am using Windows XP, with all the updates and correct timezone setting but the UTC reads '-5'.

Based on that, it seems what ST returned is correct.

--tc

[irccwh]

. . . I looked back through problem reports sent in by users and found this issue and it said the time settings on the OS need to be correct. I am using Windows XP, with all the updates and correct timezone setting but the UTC reads '-5'.

Based on that, it seems what ST returned is correct.

Huh?

(As of 7.5.1) DateAndTime>>#primitiveSystemOffset isn't correctly honoring (in windows) the return code from OSTimeZoneInformation (tz) getTimeZoneInformation which indicates whether to return (tz Bias + tz StandardBias) or (tz Bias + tz DaylightBias) to calculate the correct UTC offset for the current date/time (accounting for the -0500 vs. -0400 variation).

The correct current offset for the US east coast is -0400.

That notwithstanding, you ignored Sam's actual question/complaint which dealt with DateAndTime class>>#year:month:day:hour:minute:second:'s inability to create instances with the correct offset when the date argument is not in the current daylight savings period (the whole february vs. april thing Sam mentioned). In other words, when using DateAndTime class>>#year:month:day:hour:minute:second: the UTC offset is always determined based on the current system date, not on the resulting instance's date.

-Chad

[tc]

In other words, when using DateAndTime class>>#year:month:day:hour:minute:second: the UTC offset is always determined based on the current system date, not on the resulting instance's date.

Correct, and that is exactly how the problem reports read, the UTC offset was not being read correctly from the OS. I modified the above method to handle DST for Germany/Europe for 2008:

Code: Select all

DateAndTime class>>#year:month:day:hour:minute:second:
   "Answer a <DateAndTime> which is the second @second of the minute
    @minute of the hour @hour of the day @dayOfMonth of the month
    @month of the year @year in local time."

   | temp dstStart dstEnd |
   
   temp := self year: year month: month day: dayOfMonth hour: hour minute: minute second: second millisecond: 0 offset: self systemOffset.
   dstStart := Date new year: year month: 3 day: 30.
   dstEnd := Date new year: year month: 10 day: 26.
   (temp date >= dstStart) & (temp date < dstEnd)
      ifTrue: [ temp setOffset: temp offset + (Duration seconds: 3600) ].
   ^temp

According to the website:

http://www.timeanddate.com/time/dst2008.html

. . . DST begins at different times, most countries in Europe, it is 3/30, this year, US is 3/9. Many countries in South America do not use DST except for Argentina, for example. DST for Australia starts 10/5 in some locations but other locations do not observe DST.

The above website also says:

countries and states sometimes make adjustments that are announced just days or weeks ahead of the change.

To solve this situation, we read the UTC offset from the OS. For Java, according to the website:

http://java.sun.com/javase/timezones/

. . . when updates are done to the Java runtime installed on one's machine, DST information is read from the 'Olsen TimeZone Database' and placed on the user's machine. ST is not an underlying runtime, so, doing something like this has not been discussed.

Thanks.

--tc

[marten]

Code: Select all

   
   temp := self year: year month: month day: dayOfMonth hour: hour minute: minute second: second millisecond: 0 offset: self systemOffset.
   dstStart := Date new year: year month: 3 day: 30.
   dstEnd := Date new year: year month: 10 day: 26.
   (temp date >= dstStart) & (temp date < dstEnd)
      ifTrue: [ temp setOffset: temp offset + (Duration seconds: 3600) ].
   ^temp


No, no - this does not work. You have to make some calculation to get the start and the end of the DST and also you should consider hours to get it right. And of course you assume to use the buggy systemOffset method ...

Perhaps with a new release one should make the usage much clearer and perhaps considering stuff like
Chronos time base library may also help ....

Marten

[tc]

I agree, the correct way to do it is to use Chronos, however, they use the Olsen DB as well, I believe. To answer the OP's question about Java working, when updates are done, Java/Sun downloads the Olsen DB info in the form of compiled data files on to the computer.

I just opened the timezone settings for Win XP on my machine and it is set to Eastern US time with a UTC offset of -5. It seems to me that XP should at least have the correct offset for the current timezone, which is -4 for me.

Therefore, I disagree that systemOffset is buggy because it is reading the OS correctly. I tested it by changing timezones, different UTC offsets, and systemOffset always returned the OS UTC offset.

If one were using the Olsen DB, the OS would not be queried for the UTC offset as it is contained in the Olsen data sets.

--tc

[Sam De Block]

Ok, so maybe primitiveSystemOffset isn't broken. It return the correct timezoneoffset.
You can't deny the fact that there is basically no handling for DST times with DateAndTime.

One note on the windows thingie:
If you select GMT-5 (Eastern Time) on the Time Zone tab, the label on the 'Date & Time' tab changes to: Current time zone: Eastern Daylight Time.
--> EDT: http://www.timeanddate.com/library/abbr ... a/edt.html
Now change your month to january and click apply. The label on the 'Date & Time' tab changes to: Current time zone: Eastern Standard Time.
--> EST: http://www.timeanddate.com/library/abbr ... a/est.html

The reason we are having this problem is because we have webservices which transmit DateAndTime values to our Java client. The DateAndTime gets send over the wire as UTC, so for the moment I have 2 choices:
* Use the default primitiveSystemOffset method. All our DateAndTime's from the NON-DST period get displayed correct, DST times are wrong.
* Use the 'fixed' primitiveSystemOffset method, which keeps track of DST. All our DateAndTime's from the NON-DST period get displayed wrong and our DST times are right.

Also as marten says, you need to take the time in account if you want to decide when DST occurs.

[nmongeau]

primitiveSystemOffset is definitely broken. As Chad pointed out, under Windows, when calling GetTimeZoneInformation, the structure returned always contains the _normal_ (emphasis mine) bias from UTC, in my case, Eastern Canada, it's -5. BUT, you need to pay attention to the return value of the call, which tells you if you're currently in Standard or DaylightSaving mode, in which case you presumably need to adjust your offset from UTC.

Normand

[tc]

Hello,

I guess we need to define what 'broken' means. The purpose of primitiveSystemOffset is to read the UTC offset from the OS. In that sense, it is not broken.

If by 'broken', you mean there is no additional ST logic to modify the offset read from the OS, then it would be 'broken'.

My point before was, for the current time and day, eastern US, I would have thought that XP would have the correct UTC offset but it does not. XP currently shows -5, the correct setting would be -4 since the eastern US is observing daylight savings at the moment.

For the OP's issue, where time info is being sent via web services, the w3 document, http://www.w3.org/TR/timezone/ , talks about using time in XML and also mentions the Olsen TimeZone DB.

Using the Olsen DB is the correct way to handle time zone issues in XML (handle means processing compiled time zone data sets) and, as the OP pointed out, the ST base image does not include Olsen TZ classes.

--tc

[nmongeau]

what was not obvious in my previous post is that I assume that primitiveSystemOffset calls GetTimeZoneInformation() under Windows. Is this is so, like I said, you need to interpret the return code to adjust the UTC offset. Windows designers chose to return a "constant" UTC offset (-5 in my case), that one needs to adjust when DST is active.

[tc]

Hello,

I opened an internal problem report on the issue.

Thanks.

--tc

[irccwh]

You might already have one for the primitiveSystemOffset bug:

We'll fix this in the next major release.

Thanks,
Solveig Viste
Instantiations Smalltalk Support

http://groups.google.com/group/ibm.software.vasmalltalk/browse_thread/thread/6fa33d9022dc31df/d903c88e09e0dec6?lnk=gst&q=primitiveSystemOffset+#d903c88e09e0dec6

[tc]

The case number referred to in a previous message, from the google thread, is Case 6379.

The issue was there was no way to uniformly handle the call on all the platforms that VA Smalltalk supports.

The google thread does offer an ST/Windows only solution which can be used if the clients are windows.

Another person has the case and will work on a solution.

--tc