It has always been my intuition that Date (and Time) model has to contain the time zone the Date is supposed to represent, e.g. like in y/m/d+timezone. This way we would always have an object that precisely represents an absolute point in time. Very many problems, if not all, discussed here only arise when two instances of time magnitude are being compared. This seems to me much better addressed if taken into consideration at the time of comparison. Some conventions would have to be introduced to create deterministic response for arithmetics but at least the exposure to the complex semantics and computational overhead go away until it cannot any longer be avoided: when ultimate point in time has to be converted in line with the current legal stance of the definitions. This also hints towards the requirement for having a “time of arithmetic operation” play a role in the comparison in order to allow programmatic reasoning about date/time arithmetics as taken in the past, e.g. before a particular regulation adjusted particular semantics. In practical terms comparing a Date expressed in EST with a date expressed in Zulu could be resolved by first coercing the units both instances are expressed in, say to UTC, and then performing arithmetics. Such view also resonates with Sean’s observation below that offset of 0 seems reasonable...
Regards, Jaroslaw On Mon, 9 Apr 2018 at 17:53, Sean P. DeNigris <[email protected]> wrote: > Sven Van Caekenberghe-2 wrote > > I think that making Date always UTC will probably not help, because you > > will want to be able to move between timezones > > Two things: > - I don't think changing timezones will be affected, because my proposal is > only: "default to 0 offset for new Date[AndTime] instances where no offset > is specified". This would not prevent changing the offset later on > (although > one would make the case that since guessing default offset is unfixable in > practice in the core, it should be removed altogether), and it also > wouldn't > affect the offset of the image, so `Date today` would still use the local > offset. > - I'm not saying that it is a panacea, but it will avoid the bug in > question. It is less wrong than the current behavior and will allow those > of > us on DST to keep our sanity while we come up with a more perfect long term > solution. > > What is the downside to this change? > > > > ----- > Cheers, > Sean > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html > >
