[vwnc] Question regarding BindingBuilder class>>decodeTimestampFrom:, vw 7.4.1
Locked
[vwnc] Question regarding BindingBuilder class>>decodeTimestampFrom:, vw 7.4.1
 
|
Hello list,
We are running into the following problem with one of our Finnish customers. The problem arises when using a SOAP service using a time stamp as parameter... * First some context: In our application we include functionality that logs changes to certain objects to the database. For example: if a user changes the 'contractNumber' aspect of a Contract object from 00001 to 00005, this will be logged to the db as a record: [October 13, 2008 16:57:19.000 | contractNumber | 00001 | 00005 ] The meaning of this record is: [timestamp of the change | name of the aspect | old value | new value] Please note that the timestamp contains the local time at the moment of the change. Also, we allow our customers the query those changes through a SOAP service. This is done using an operation getProgramChangeLogsSince: aTimestamp. This parameter is of the type Timestamp, the corresponding xml type a dateTime. * Now, when providing a certain timestamp (in the case of our Finnish guys: '2002-08-02T13:20:00+02:00') as argument to the SOAP operation, this xml dateTime is converted to a Timestamp Smalltalk object in the method BindingBuilder class>>decodeTimestampFrom:. It seems that the given argument is converted to UTC first, and then back again to local time. Our problem is that timestamps containing a date in summer have an extra hour added during the conversion because of daylight saving time: e.g. BindingBuilder decodeTimestampFrom: '2008-03-01T13:00:00+02:00' yields: 1 March 2008 13:00:00.000 BindingBuilder decodeTimestampFrom: '2008-05-01T13:00:00+02:00' yields: 1 May 2008 14:00:00.000 This is a problem, because if a change log C is written to the DB on 1st May, at 13:30, and our customer queries all changes from '2008-05-01T13:00:00+02:00', the xml will only return all changes since 14:00 instead of 13:00. Therefore the change log C will not be returned. The actual question is: how should we work around this? Is this a bug in decodeTimestampFrom:? Does the timezone part of dateTime point to the actual timezone offset (so we should use +03:00 during summer)? What are we missing here? Any ideas? This is in vw7.4.1. Thanks, Philippe _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
|
|
"Philippe Demaecker"<[hidden email]> wrote:
> BindingBuilder decodeTimestampFrom: '2008-03-01T13:00:00+02:00' > yields: 1 March 2008 13:00:00.000 > > BindingBuilder decodeTimestampFrom: '2008-05-01T13:00:00+02:00' > yields: 1 May 2008 14:00:00.000 > What you get is a Timestamp object converted to an equivalent time in the current timezone (TimeZone default), unless the timezone in the image where you run the above expression doesn't have DST set, the results should be different the way you describe, because the May time expressed above would fall into DST, so the clock time at that point would be an our ahead. > This is a problem, because if a change log C is written to the DB on 1st May, at 13:30, and our customer queries all changes from '2008-05-01T13:00:00+02:00', the xml will only return all changes since 14:00 instead of 13:00. Actually it seems to me that the change log would be wrong in this case, because if it's DST time the offset should chan! ge from +02:00, to +03:00, otherwise the log entry is simply incorrect. The +02:00 means 2 hours ahead from UTC, but during the DST period it is 3 hours ahead, right ? >Therefore the change log C will not be returned. The actual question is: how should we work around this? Is this a bug in decodeTimestampFrom:? Does the timezone part of dateTime point to the actual timezone offset (so we should use +03:00 during summer)? What are we missing here? I'm not entirely sure what's wrong here, I feel I'm missing some parts of the picture. But as I suggested above, I'd expect the log entries to change between +02:00 and +03:00 with respect to DST, or they should be just all converted to UTC. Either way you have to make sure you're comparing compatible values. Timestamp is not absolute, it is always in reference to a TimeZone (usually TimeZone default). So you have to make sure both compared values are first converted to the same reference zone. HTH, Martin _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Re: [vwnc] Question regarding BindingBuilder class>>decodeTimestampFrom:, vw 7.4.1
|
|
Hello Martin, It seems that the time zone part of
dateTime actually reflects the _offset_ to UTC time, not the actual _time zone_. (see: http://www.w3.org/TR/timezone/#d2e131). It seems therefore that for datetimes
during DST we should use something like '2008-05-01T13:00:00+03:00', for dateTimes during winter time: '2008-03-01T13:00:00+02:00' This will make the query work, since our
change log time stamps are always stored in local time (the offset to UTC of
those timestamps is indeed +3 during DST, +2 otherwise). Thanks for you insights, Philippe ---------- Forwarded
message ---------- "Philippe Demaecker"<[hidden email]>
wrote: What you get is a Timestamp object converted to an equivalent time in
the current timezone (TimeZone default), unless the timezone in the image where
you run the above expression doesn't have DST set, the results should be
different the way you describe, because the May time expressed above would fall
into DST, so the clock time at that point would be an our ahead.
Actually it seems to me that the change log would be wrong in this
case, because if it's DST time the offset should change from +02:00, to +03:00,
otherwise the log entry is simply incorrect. The +02:00 means 2 hours ahead
from UTC, but during the DST period it is 3 hours ahead, right ?
I'm not entirely sure what's wrong here, I feel I'm missing some parts
of the picture. But as I suggested above, I'd expect the log entries to change
between +02:00 and +03:00 with respect to DST, or they should be just all
converted to UTC. Either way you have to make sure you're comparing compatible
values. Timestamp is not absolute, it is always in reference to a TimeZone
(usually TimeZone default). So you have to make sure both compared values are
first converted to the same reference zone. _______________________________________________ _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
| Free forum by Nabble | Edit this page |