On Tue, Oct 23, 2018 at 10:17 AM Sean P. DeNigris sean@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