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

Reply via email to