[Pharo-project] Problem with Date comparing summer time CEST
I have an attribute "date" in a domain object. Last week, I created some objects with this attribute. Today I created objects again with the same date value in this attribute. When comparing the dates (=), the result is false. Reason is, that in germany, we had a switch from Central European Summer Time (CEST) (Sommerzeit) to Daylight Saving Time (DST) this weekend. Date has an attribute "start" which has an instance of DateAndTime. This DateAndTime object has another value depending on the CEST/DST 2012-10-02T00:00:00+*01:00* (DST) 2012-10-02T00:00:00+*02:00* (CEST) When I create two Dates with same date, I expect that = evaluates to true, independent from the CEST/DST. But Date (Timespan) uses /= comparand ^ self class = comparand class and: [ *self start = comparand start * and: [ self duration = comparand duration ]]/ What do you recommend? Create my own compare method? Did I miss something? -- View this message in context: http://forum.world.st/Problem-with-Date-comparing-summer-time-CEST-tp4653354... Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
I have an attribute "date" in a domain object. Last week, I created some objects with this attribute. Today I created objects again with the same date value in this attribute. When comparing the dates (=), the result is false.
Reason is, that in germany, we had a switch from Central European Summer Time (CEST) (Sommerzeit) to Daylight Saving Time (DST) this weekend.
Date has an attribute "start" which has an instance of DateAndTime. This DateAndTime object has another value depending on the CEST/DST
2012-10-02T00:00:00+
01:00
(DST) 2012-10-02T00:00:00+
02:00
(CEST)
When I create two Dates with same date, I expect that = evaluates to true, independent from the CEST/DST. But Date (Timespan) uses / = comparand ^ self class = comparand class and: [
self start = comparand start
Sabine Knöfel wrote * * * * * *
and: [ self duration = comparand duration ]]
/
What do you recommend? Create my own compare method? Did I miss something?
Localized dates and times are awful to mess with because the timing of the daylight savings transitions are political and vary from place to place and year to year. This is good advice from Tom Rushworth on comparing dates: http://forum.world.st/Should-Dates-be-Timezone-specific-tp3647678p3649107.ht... Also on Squeaksource the TimeZoneDatabase and Chronos packages have mechanisims for keeping up to date about when offsets should be changed in the image. For me, my image's internal timezone is set to UTC. I use Chronos and store everything as UTC, use UTC values for every calculation, then convert it back to the local time only on display to a user. -- View this message in context: http://forum.world.st/Problem-with-Date-comparing-summer-time-CEST-tp4653354... Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
If you're on 1.4 you have serious issues when moving between timezones (in this case the winter/summer time switch) see https://code.google.com/p/pharo/issues/detail?id=5919 and http://forum.world.st/Bug-in-DateAndTime-td2293749.html the problem is, that the reference point was not defined in a fixed time-zone but rather relative, which breaks under certain conditions!! On 2012-10-30, at 22:20, Paul DeBruicker <pdebruic@gmail.com> wrote:
I have an attribute "date" in a domain object. Last week, I created some objects with this attribute. Today I created objects again with the same date value in this attribute. When comparing the dates (=), the result is false.
Reason is, that in germany, we had a switch from Central European Summer Time (CEST) (Sommerzeit) to Daylight Saving Time (DST) this weekend.
Date has an attribute "start" which has an instance of DateAndTime. This DateAndTime object has another value depending on the CEST/DST
2012-10-02T00:00:00+
01:00
(DST) 2012-10-02T00:00:00+
02:00
(CEST)
When I create two Dates with same date, I expect that = evaluates to true, independent from the CEST/DST. But Date (Timespan) uses / = comparand ^ self class = comparand class and: [
self start = comparand start
Sabine Knöfel wrote * * * * * *
and: [ self duration = comparand duration ]]
/
What do you recommend? Create my own compare method? Did I miss something?
Localized dates and times are awful to mess with because the timing of the daylight savings transitions are political and vary from place to place and year to year.
This is good advice from Tom Rushworth on comparing dates: http://forum.world.st/Should-Dates-be-Timezone-specific-tp3647678p3649107.ht...
Also on Squeaksource the TimeZoneDatabase and Chronos packages have mechanisims for keeping up to date about when offsets should be changed in the image.
For me, my image's internal timezone is set to UTC. I use Chronos and store everything as UTC, use UTC values for every calculation, then convert it back to the local time only on display to a user.
-- View this message in context: http://forum.world.st/Problem-with-Date-comparing-summer-time-CEST-tp4653354... Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
On 30 Oct 2012, at 22:20, Paul DeBruicker <pdebruic@gmail.com> wrote:
For me, my image's internal timezone is set to UTC. I use Chronos and store everything as UTC, use UTC values for every calculation, then convert it back to the local time only on display to a user.
Yes, Paul: this is the only way to remain sane ;-) That is one of the reasons why I wrote ZTimestamp, a point-in-time alternative to DateAndTime and TimeStamp with second precision, living in UTC, using ISO/International conventions and protocols only. http://mc.stfx.eu/Neo Sven -- Sven Van Caekenberghe http://stfx.eu Smalltalk is the Red Pill
On 2012-10-30, at 22:33, Sven Van Caekenberghe <sven@stfx.eu> wrote:
On 30 Oct 2012, at 22:20, Paul DeBruicker <pdebruic@gmail.com> wrote:
For me, my image's internal timezone is set to UTC. I use Chronos and store everything as UTC, use UTC values for every calculation, then convert it back to the local time only on display to a user.
right, just for completeness, in 2.0 all time objects are stored in UTC. Additionally they store the timezone, used for conversions and displaying.
Yes, Paul: this is the only way to remain sane ;-)
That is one of the reasons why I wrote ZTimestamp, a point-in-time alternative to DateAndTime and TimeStamp with second precision, living in UTC, using ISO/International conventions and protocols only.
we should actually consider putting that into pharo ;) I guess we can do a quick discussion round at the sprint on Friday...
On 30 Oct 2012, at 23:09, Camillo Bruni <camillobruni@gmail.com> wrote:
Yes, Paul: this is the only way to remain sane ;-)
That is one of the reasons why I wrote ZTimestamp, a point-in-time alternative to DateAndTime and TimeStamp with second precision, living in UTC, using ISO/International conventions and protocols only.
we should actually consider putting that into pharo ;) I guess we can do a quick discussion round at the sprint on Friday...
OK! BTW: I have a half done implementation of ZTimestampFormat based on example strings as specification for formatting & parsing as well ;-) -- Sven Van Caekenberghe http://stfx.eu Smalltalk is the Red Pill
On 2012-10-30, at 23:32, Sven Van Caekenberghe <sven@stfx.eu> wrote:
On 30 Oct 2012, at 23:09, Camillo Bruni <camillobruni@gmail.com> wrote:
Yes, Paul: this is the only way to remain sane ;-)
That is one of the reasons why I wrote ZTimestamp, a point-in-time alternative to DateAndTime and TimeStamp with second precision, living in UTC, using ISO/International conventions and protocols only.
we should actually consider putting that into pharo ;) I guess we can do a quick discussion round at the sprint on Friday...
OK!
BTW: I have a half done implementation of ZTimestampFormat based on example strings as specification for formatting & parsing as well ;-)
aah nice!
Thank you. I want to set the UTC Timezone (DateAndTime localTimeZone: TimeZone default) at startUp of my image. Witch is the correct place to put this in? On Wed, Oct 31, 2012 at 9:19 AM, Camillo Bruni <camillobruni@gmail.com> wrote:
On 2012-10-30, at 23:32, Sven Van Caekenberghe <sven@stfx.eu> wrote:
On 30 Oct 2012, at 23:09, Camillo Bruni <camillobruni@gmail.com> wrote:
Yes, Paul: this is the only way to remain sane ;-)
That is one of the reasons why I wrote ZTimestamp, a point-in-time alternative to DateAndTime and TimeStamp with second precision, living in UTC, using ISO/International conventions and protocols only.
we should actually consider putting that into pharo ;) I guess we can do a quick discussion round at the sprint on Friday...
OK!
BTW: I have a half done implementation of ZTimestampFormat based on example strings as specification for formatting & parsing as well ;-)
aah nice!
-- PS: Bitte Stimme für meine Schwester abgeben: http://www.sterne-des-handwerks.de/voting/wettbewerb/detail/teilnehmer/4678....
On Oct 30, 2012, at 11:09 PM, Camillo Bruni wrote:
On 2012-10-30, at 22:33, Sven Van Caekenberghe <sven@stfx.eu> wrote:
On 30 Oct 2012, at 22:20, Paul DeBruicker <pdebruic@gmail.com> wrote:
For me, my image's internal timezone is set to UTC. I use Chronos and store everything as UTC, use UTC values for every calculation, then convert it back to the local time only on display to a user.
right, just for completeness, in 2.0 all time objects are stored in UTC. Additionally they store the timezone, used for conversions and displaying.
Yes, Paul: this is the only way to remain sane ;-)
That is one of the reasons why I wrote ZTimestamp, a point-in-time alternative to DateAndTime and TimeStamp with second precision, living in UTC, using ISO/International conventions and protocols only.
we should actually consider putting that into pharo ;) I guess we can do a quick discussion round at the sprint on Fridayâ¦
yeap!
participants (5)
-
Camillo Bruni -
Paul DeBruicker -
Sabine Knöfel -
Stéphane Ducasse -
Sven Van Caekenberghe