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
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