Bug with DateAndTime / Time abtXmlFromString:

VA Smalltalk is a "100% VisualAge compatible" IDE that includes the original VisualAge technology and the popular VA Assist and WidgetKit add-ons.

Moderators: Eric Clayberg, wembley, tc, Diane Engles, solveig

Bug with DateAndTime / Time abtXmlFromString:

Postby Sam De Block » Thu Sep 27, 2007 6:19 am

I'm having a problem when deserializing DateAndTime and Time objects.
I'm testing this in Belgium which is UTC+1 and Daylight savings is in use.

A) (DateAndTime abtXmlFromString: '2007-09-27T15:00:00Z') asLocal time displays 16:00:00
B) (Time abtXmlFromString: '15:00:00Z') also displays 16:00:00

A) This Should display 17:00 because: 15:00 UTC + 1hour from timezone + 1 hour from DST = 17:00
B) This is correct, because Time doesn't keep track of a date and rightfully ignores DST, so: 15:00 + 1 hour from timezone = 16:00.


Now if we replace DateAndTime primitiveSystemOffset with the following code:
Code: Select all
primitiveSystemOffset
   | 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


we reverse the problem, because then
A display the correct answer, which is 17:00.
Because Time uses the same logic as in DateAndTime, B also displays 17:00 which is incorrect.
Sam De Block
 
Posts: 17
Joined: Thu Nov 09, 2006 4:25 am

Re: Bug with DateAndTime / Time abtXmlFromString:

Postby marten » Fri Sep 28, 2007 12:57 am

Sam De Block wrote:Because Time uses the same logic as in DateAndTime, B also displays 17:00 which is incorrect.


Should it be 16:00 ? The method implementation now returns "local" time. But reading the comment I would suggest, that it should return UTC time ... and this should be still 15:00 time (in your example) .... otherwise one would loose the time zone information after reading the string. And when you write the string back into your XML file, you actually write back a false time information ....

Perhaps one should change (??) it to:

abtXmlFromString: aString
" Create a new Time instance using the contents of @aString. Time format is ISO8601. Use logic in DateAndTime so that optional timezone indicator
can be properly processed. Since the Time object cannot represent the timeZone, the time is represented as UTC "


^( DateAndTime abtXmlFromTimeString: aString ) ifNotNil: [:aDateTime | aDateTime asUTC time ]

On the other hand printString should also print "15:00:00Z" and not only "15:00:00", because when reading this value again it is interpreted as local time and you have the same problem again.

Marten
marten
[|]
 
Posts: 641
Joined: Sat Oct 14, 2006 7:10 am
Location: Hamburg - Germany

Re: Bug with DateAndTime / Time abtXmlFromString:

Postby Sam De Block » Mon Oct 01, 2007 12:17 am

marten wrote:
Sam De Block wrote:Because Time uses the same logic as in DateAndTime, B also displays 17:00 which is incorrect.


Should it be 16:00 ? The method implementation now returns "local" time. But reading the comment I would suggest, that it should return UTC time ... and this should be still 15:00 time (in your example) .... otherwise one would loose the time zone information after reading the string. And when you write the string back into your XML file, you actually write back a false time information ....

We wouldnt write back false information, because it should write (local time - UTC offset) to the xml.
marten wrote:Perhaps one should change (??) it to:

abtXmlFromString: aString
" Create a new Time instance using the contents of @aString. Time format is ISO8601. Use logic in DateAndTime so that optional timezone indicator
can be properly processed. Since the Time object cannot represent the timeZone, the time is represented as UTC "

^( DateAndTime abtXmlFromTimeString: aString ) ifNotNil: [:aDateTime | aDateTime asUTC time ]

Although I agree the method comment is wrong, this wouldnt really change anything.

I've tested this with Java and .Net and they both do the following:
When sending a date and time: DST offset is used.
When only sending a time, DST offset isnt used.
Which makes perfectly good sense, because without a date you don't know if DST is in use.

Anyway, I'd like to see this fixed. :)
Sam De Block
 
Posts: 17
Joined: Thu Nov 09, 2006 4:25 am

Re: Bug with DateAndTime / Time abtXmlFromString:

Postby marten » Mon Oct 01, 2007 2:44 am

Sam De Block wrote:
marten wrote:
Sam De Block wrote:Because Time uses the same logic as in DateAndTime, B also displays 17:00 which is incorrect.


Should it be 16:00 ? The method implementation now returns "local" time. But reading the comment I would suggest, that it should return UTC time ... and this should be still 15:00 time (in your example) .... otherwise one would loose the time zone information after reading the string. And when you write the string back into your XML file, you actually write back a false time information ....

We wouldnt write back false information, because it should write (local time - UTC offset) to the xml.
marten wrote:Perhaps one should change (??) it to:

abtXmlFromString: aString
" Create a new Time instance using the contents of @aString. Time format is ISO8601. Use logic in DateAndTime so that optional timezone indicator
can be properly processed. Since the Time object cannot represent the timeZone, the time is represented as UTC "

^( DateAndTime abtXmlFromTimeString: aString ) ifNotNil: [:aDateTime | aDateTime asUTC time ]

Although I agree the method comment is wrong, this wouldnt really change anything.

I've tested this with Java and .Net and they both do the following:
When sending a date and time: DST offset is used.
When only sending a time, DST offset isnt used.
Which makes perfectly good sense, because without a date you don't know if DST is in use.

Anyway, I'd like to see this fixed. :)


Ok, when searching for explanations about the 8601-standard, I've found the following stuff:

When a "time of a day" is needed and it is printed like "15:00:00" it is meant in the context of the writer and means current legal time - whatever this means.

If this is not clear (and the "document" may be used anywhere on the world) the writer should add time zone informations to the "time of day" information like "Z" for the UTC time zone or the offset (+/-hh:mm ...)

The writer therefore should follow the DateTime ISO-8601 convention.

For me this means, that time-only information may contain time-zone information. If this is not possible (as in class Time) it makes sense to hold all information internal as UTC and convert it whenever needed when printing the information.

If I have an textual input of '15:00:00' this means my local legal time (standard time or DST - in my actual receiving context) and Smalltalk should convert this (internally) to UTC. This means, that it must use DST to do conversion in a correct way. Its obvious, that this may lead to errors - depending on the date of interpretation it may lead to wrong results.

If I do not want to have these problems I have to add time zone informations to my time representation like "Z" or "+/-hh" ...

Time class>>abtXmlFromString: aString

now gets '15:00:00' and interprets this (correctly) as local legal time, makes the correct conversion (considering the error of primitiveSystemOffset is fixed some time in the future), via converting it to "15:00:00+02:00" (in my case: CET plus DST) and then convert it back to local legal time (removing the +02:00).

In case of '15:00:00Z' it converts to "15:00:00+00:00" and then converts it back to local legal time (adding the +02:00) and comes back with: '17:00'.

After all the behaviour is consistent and I think, that VA does correctly prints the values (considering the primitiveOffset fix) - also my suggested patch would break the VA logic.

But the "main problem" is, that VA converts the time values back to local time (internally) - and then you get the problem, that you may loose the time zone information. Therefore the precise information "15:00:00Z" is converted to "17:00:00" - the base has been lost ... and around Christmas you do not know, if it was "15:00:00Z" or "16:00:00Z" any more.

Changing the internal representation of class Time to UTC would solve the logical problem, but would break compatibility - stuff like "aTime hours >= 12" would got broken, because most of us would think in local time ... we would need additional methods like "asLocalHours", "asLocalMinutes", "asLocalSeconds" ...

Summary for me: my suggested fix is wrong, VASmalltalk does it (as much as it can do it according to the circumstances (bugs and internal logic)) correct and you expect the wrong values - because you have to take the DST into account, when doing conversion.

The best thing would be to have a Time class with an additional time zone offset. Then the time values are coded in local values and actually we would therefore have code compatibility, because the initial value of the offset would be the actual primitiveSystemOffset, when creating the instance or when reloaded from databases ....

Marten
marten
[|]
 
Posts: 641
Joined: Sat Oct 14, 2006 7:10 am
Location: Hamburg - Germany

Postby Sam De Block » Mon Oct 01, 2007 5:22 am

To summarize:
a) DateAndTime abtXmlFromString is broken because primitiveSystemOffset only returns UTC offset (which doesnt include DST).

b) The key question for Time is: if I have a local time of 17:00 and I'm at UTC+1 with DST should we serialize this as 16:00 UTC or as 15:00 UTC?
Sam De Block
 
Posts: 17
Joined: Thu Nov 09, 2006 4:25 am

Postby marten » Mon Oct 01, 2007 6:15 am

Sam De Block wrote:To summarize:
b) The key question for Time is: if I have a local time of 17:00 and I'm at UTC+1 with DST should we serialize this as 16:00 UTC or as 15:00 UTC?


I would interpret a string "17:00:00" coming from you as "15:00:00Z" or "17:00:00+02.00" (my time zone - and yours but that does not care). But in a month (no DST) I have to interpret the same "17:00:00" as "16:00:00Z" or "17:00:00+01.00".

Marten
marten
[|]
 
Posts: 641
Joined: Sat Oct 14, 2006 7:10 am
Location: Hamburg - Germany

Postby marten » Mon Oct 01, 2007 6:51 am

Sam De Block wrote:To summarize:
a) DateAndTime abtXmlFromString is broken because primitiveSystemOffset only returns UTC offset (which doesnt include DST).

b) The key question for Time is: if I have a local time of 17:00 and I'm at UTC+1 with DST should we serialize this as 16:00 UTC or as 15:00 UTC?


Another example in C#:

DateTime aDateTime = DateTime.Parse("17:00:00");
System.Console.WriteLine(aDateTime.ToUniversalTime().ToString());
System.Console.ReadLine();

prints today: "01.10.2007 15:00:00"

and next month: "01.11.2007 16:00:00"

Marten
marten
[|]
 
Posts: 641
Joined: Sat Oct 14, 2006 7:10 am
Location: Hamburg - Germany


Return to VA Smalltalk 7.0, 7.5 & 8.0

Who is online

Users browsing this forum: Yahoo [Bot] and 1 guest