Creating Dates before/after Daylight Saving Time change
Hello, 1) when I create date on: 2017/03/20 (before Daylight Saving Time change) with this code: D1 := Date year: 2017 month: 3 day: 26. Date object is created with instvars: start: 2017-03-26T00:00:00+01:00 duration: 1:00:00:00 2) when I create same Date instance with the same code on/after: 2017/03/26 (after Daylight Saving Time change): D2 := Date year: 2017 month: 3 day: 26. Date instance with this instvars returned: start: 2017-03-26T00:00:00+02:00 duration: 1:00:00:00 3) D1 != D2 So, for example: persisted instance of date (Date year: 2017 month: 3 day: 26) created before DST change is not equal with date instance (Date year: 2017 month: 3 day: 26) created after DST change. DST change breaks equality of the same date :( Is it OK? Thanks! Petr Fischer
Date>>year:month:day: (respectively Date>>#starting:) is using DateAndTime to specify the start, and DateAndTime will of course differ. To me it seems like someone was reusing implementation; because Date normally shouldn't have/care about time information, and yet it subclasses from Timespan class, which has/cares about time information. So the Date is actually encoded in Timespan's 'starting' instVar as DateAndTime instance, which is obviously breaking if TimeZone is applied. Maybe a fix (apart from not using Time in Date) would be to make sure Date's methods use DateAndTime offset to 0? Because even without daylight saving, if you create a Date instance in one country, and move to different TZ it should break; so always keeping it UTC/0 would make sense to me. Peter On Sun, Mar 26, 2017 at 10:17:14AM +0200, Petr Fischer wrote:
Hello,
1) when I create date on: 2017/03/20 (before Daylight Saving Time change) with this code:
D1 := Date year: 2017 month: 3 day: 26.
Date object is created with instvars: start: 2017-03-26T00:00:00+01:00 duration: 1:00:00:00
2) when I create same Date instance with the same code on/after: 2017/03/26 (after Daylight Saving Time change):
D2 := Date year: 2017 month: 3 day: 26.
Date instance with this instvars returned: start: 2017-03-26T00:00:00+02:00 duration: 1:00:00:00
3) D1 != D2
So, for example: persisted instance of date (Date year: 2017 month: 3 day: 26) created before DST change is not equal with date instance (Date year: 2017 month: 3 day: 26) created after DST change. DST change breaks equality of the same date :(
Is it OK?
Thanks! Petr Fischer
Even "Date today" and "Date now" is created by DateAndTime. So, due to the DateAndTime internals, one can't persist Date instance (eg. with Fuel) and use it as exact "date/day value" for comparisons later in time (when GST changes back and forth). The same date value (one created before DST change, one created after DST change) will be different even in long run (on the DST change day - Date today in created on 1:00am will be different from Date today created on 2:00 am - weird! it's the same day!). Isn't the usage of "time" component in Date class a bug (at least in comparison #= method)? What about to redefine #= instance method in Date class (it's defined in Timespan super class now)? = comparand ^ self species = comparand species and: [ self translateToUTC = comparand translateToUTC ]. Opinions? pf
Date>>year:month:day: (respectively Date>>#starting:) is using DateAndTime to specify the start, and DateAndTime will of course differ.
To me it seems like someone was reusing implementation; because Date normally shouldn't have/care about time information, and yet it subclasses from Timespan class, which has/cares about time information. So the Date is actually encoded in Timespan's 'starting' instVar as DateAndTime instance, which is obviously breaking if TimeZone is applied.
Maybe a fix (apart from not using Time in Date) would be to make sure Date's methods use DateAndTime offset to 0? Because even without daylight saving, if you create a Date instance in one country, and move to different TZ it should break; so always keeping it UTC/0 would make sense to me.
Peter
On Sun, Mar 26, 2017 at 10:17:14AM +0200, Petr Fischer wrote:
Hello,
1) when I create date on: 2017/03/20 (before Daylight Saving Time change) with this code:
D1 := Date year: 2017 month: 3 day: 26.
Date object is created with instvars: start: 2017-03-26T00:00:00+01:00 duration: 1:00:00:00
2) when I create same Date instance with the same code on/after: 2017/03/26 (after Daylight Saving Time change):
D2 := Date year: 2017 month: 3 day: 26.
Date instance with this instvars returned: start: 2017-03-26T00:00:00+02:00 duration: 1:00:00:00
3) D1 != D2
So, for example: persisted instance of date (Date year: 2017 month: 3 day: 26) created before DST change is not equal with date instance (Date year: 2017 month: 3 day: 26) created after DST change. DST change breaks equality of the same date :(
Is it OK?
Thanks! Petr Fischer
Did you check the Zn counterpart because I know that some parts are much better. But I do not have them at hand. Stef On Sun, Mar 26, 2017 at 10:17 AM, Petr Fischer <petr.fischer@me.com> wrote:
Hello,
1) when I create date on: 2017/03/20 (before Daylight Saving Time change) with this code:
D1 := Date year: 2017 month: 3 day: 26.
Date object is created with instvars: start: 2017-03-26T00:00:00+01:00 duration: 1:00:00:00
2) when I create same Date instance with the same code on/after: 2017/03/26 (after Daylight Saving Time change):
D2 := Date year: 2017 month: 3 day: 26.
Date instance with this instvars returned: start: 2017-03-26T00:00:00+02:00 duration: 1:00:00:00
3) D1 != D2
So, for example: persisted instance of date (Date year: 2017 month: 3 day: 26) created before DST change is not equal with date instance (Date year: 2017 month: 3 day: 26) created after DST change. DST change breaks equality of the same date :(
Is it OK?
Thanks! Petr Fischer
On 26 Mar 2017, at 21:56, Stephane Ducasse <stepharo.self@gmail.com> wrote:
Did you check the Zn counterpart because I know that some parts are much better. But I do not have them at hand.
You mean ZTimestamp (but it is not a part of Zinc HTTP Components). https://github.com/svenvc/ztimestamp This is an UTC, second precision timestamp without TZ info, and a number of interesting tools. However, that won't solve the issue raised. Some people think of a date as an abstract calendar date, while for others its a concrete day (my Monday is not your Monday if we are in different time zones). I don't think there is only one solution, both roles are needed/useful. Note that STON serialises Dates as YYYY-MM-DD which is what you seem to want. The ZTimezone class knows about the exact transitions, but that still does not mean that no weird things happen at the transition point, au contraire ;-)
Stef
On Sun, Mar 26, 2017 at 10:17 AM, Petr Fischer <petr.fischer@me.com> wrote: Hello,
1) when I create date on: 2017/03/20 (before Daylight Saving Time change) with this code:
D1 := Date year: 2017 month: 3 day: 26.
Date object is created with instvars: start: 2017-03-26T00:00:00+01:00 duration: 1:00:00:00
2) when I create same Date instance with the same code on/after: 2017/03/26 (after Daylight Saving Time change):
D2 := Date year: 2017 month: 3 day: 26.
Date instance with this instvars returned: start: 2017-03-26T00:00:00+02:00 duration: 1:00:00:00
3) D1 != D2
So, for example: persisted instance of date (Date year: 2017 month: 3 day: 26) created before DST change is not equal with date instance (Date year: 2017 month: 3 day: 26) created after DST change. DST change breaks equality of the same date :(
Is it OK?
Thanks! Petr Fischer
Thanks for tips to external Date/Time implementation. I implemented custom #= and #< methods in Date class as extension to solve my issue. It's sad a little, that base Date/Time classes is not enough and external libs existed. pf
On 26 Mar 2017, at 21:56, Stephane Ducasse <stepharo.self@gmail.com> wrote:
Did you check the Zn counterpart because I know that some parts are much better. But I do not have them at hand.
You mean ZTimestamp (but it is not a part of Zinc HTTP Components).
https://github.com/svenvc/ztimestamp
This is an UTC, second precision timestamp without TZ info, and a number of interesting tools.
However, that won't solve the issue raised. Some people think of a date as an abstract calendar date, while for others its a concrete day (my Monday is not your Monday if we are in different time zones).
I don't think there is only one solution, both roles are needed/useful.
Note that STON serialises Dates as YYYY-MM-DD which is what you seem to want.
The ZTimezone class knows about the exact transitions, but that still does not mean that no weird things happen at the transition point, au contraire ;-)
Stef
On Sun, Mar 26, 2017 at 10:17 AM, Petr Fischer <petr.fischer@me.com> wrote: Hello,
1) when I create date on: 2017/03/20 (before Daylight Saving Time change) with this code:
D1 := Date year: 2017 month: 3 day: 26.
Date object is created with instvars: start: 2017-03-26T00:00:00+01:00 duration: 1:00:00:00
2) when I create same Date instance with the same code on/after: 2017/03/26 (after Daylight Saving Time change):
D2 := Date year: 2017 month: 3 day: 26.
Date instance with this instvars returned: start: 2017-03-26T00:00:00+02:00 duration: 1:00:00:00
3) D1 != D2
So, for example: persisted instance of date (Date year: 2017 month: 3 day: 26) created before DST change is not equal with date instance (Date year: 2017 month: 3 day: 26) created after DST change. DST change breaks equality of the same date :(
Is it OK?
Thanks! Petr Fischer
Hi Sven, i completely agree my monday is not necessarily your monday, but my monday is my monday independently of when i initiate it. my monday (a few days ago) does _not begin at another utc because of a dst change in the meantime. this behaviour could result in additional problems, apart from Petrs, eg in a program that wants to calc the position of a star for a certain date & time. werner On 03/26/2017 10:14 PM, Sven Van Caekenberghe wrote:
On 26 Mar 2017, at 21:56, Stephane Ducasse <stepharo.self@gmail.com> wrote:
Did you check the Zn counterpart because I know that some parts are much better. But I do not have them at hand. You mean ZTimestamp (but it is not a part of Zinc HTTP Components).
https://github.com/svenvc/ztimestamp
This is an UTC, second precision timestamp without TZ info, and a number of interesting tools.
However, that won't solve the issue raised. Some people think of a date as an abstract calendar date, while for others its a concrete day (my Monday is not your Monday if we are in different time zones).
I don't think there is only one solution, both roles are needed/useful.
Note that STON serialises Dates as YYYY-MM-DD which is what you seem to want.
The ZTimezone class knows about the exact transitions, but that still does not mean that no weird things happen at the transition point, au contraire ;-)
Stef
On Sun, Mar 26, 2017 at 10:17 AM, Petr Fischer <petr.fischer@me.com> wrote: Hello,
1) when I create date on: 2017/03/20 (before Daylight Saving Time change) with this code:
D1 := Date year: 2017 month: 3 day: 26.
Date object is created with instvars: start: 2017-03-26T00:00:00+01:00 duration: 1:00:00:00
2) when I create same Date instance with the same code on/after: 2017/03/26 (after Daylight Saving Time change):
D2 := Date year: 2017 month: 3 day: 26.
Date instance with this instvars returned: start: 2017-03-26T00:00:00+02:00 duration: 1:00:00:00
3) D1 != D2
So, for example: persisted instance of date (Date year: 2017 month: 3 day: 26) created before DST change is not equal with date instance (Date year: 2017 month: 3 day: 26) created after DST change. DST change breaks equality of the same date :(
Is it OK?
Thanks! Petr Fischer
participants (5)
-
Peter Uhnak -
Petr Fischer -
Stephane Ducasse -
Sven Van Caekenberghe -
werner kassens