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 >
