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