On Tue, Oct 23, 2018 at 10:17 AM Sean P. DeNigris <sean at clipperadams.com> wrote:
>
> Chris Muller-4 wrote
> >                  1) "local" e.g., a period that begins from 12am to
> > 11:59:59.999999 of my LOCAL time,
>
> Not to reignite the long and numerous debates on the topic, but IHMO the
> seemingly unresolvable (in-practice) problem with appending offsets to
> historical dates is the offset-changing effect of daylight savings time.
> What we want to know is "the offset of my local time on the date in
> question", but all we know is "the local offset today". This leads to subtle
> bugs like:
> "executed just before DST"
> timestamp := '1/1/2016' asDate start.
> "executed just after"
> timestamp = '1/1/2016' asDate start "false - WTH!"

The above example was fixed in Squeak in 2011 by introducing Timespan
class>>#defaultOffset (which at the time was Duration zero, but has
since been changed to nil) for Timespan instances (incl. Date, Month,
Year), and letting all future created instances "inherit" their
TZ-context from whatever other source / calculation that created them.
Since Timespans (incl. Date, Month, Year) created via the class
constructors have no such TZ-context, they assume the #defaultOffset,
and any instances that emerge from calculations, etc. from those, will
assume that same no-TZ context, too.  Kinda like a virus...

> The only solution seems to be more seriously modeling timezones w.r.t. all
> the dates effecting them via an external authority. This is a nasty bug and
> again IMHO is probably better not to provide this kind of behavior at all
> rather than provide it in a subtly wrong way.

I agree with your sentiments about bug types, but I don't think this
case is that serious.  Yes, it can and has been confusing for
developers new to Squeak before they understand that Dates's can be
_local_, and indeed do inherit that property from
DateAndTime>>#asDate.  But that's pretty much the only confusing one
and my hope is that by adding #asCanonicalDate, it will be "seen" by
them and help accelerate that learning curve.   Once they know, it's
pretty easy to know, in any code context, where a #beCanonical
conversion might be needed.

Best,
  Chris