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