On Wed, Feb 17, 2016 at 06:49:03PM -0800, Bert Freudenberg wrote:
I committed a more invasive ???fix???. Looking forward to your overhaul!
Btw, I discovered that utcMicrosecondClock differs from primPosixMicrosecondClockWithOffset - the VM must use a different way to get its time. I worked around that by not using the non-offset prims at all, but it may lead to problems.
In any case, the image now automatically uses the OS???s time zone as reported by primPosixMicrosecondClockWithOffset. To make the tests green I had to make TimeSpan comparison more lenient (treating defaultOffset as wildcard). Basically, if a Date has no timezone set then it will match a Date in any time zone as long as they ???look??? the same. Possibly a better idea would be to have different classes for dates with and without timezones, but then that may be even more confusing.
I think that all we really need is a clear definition of whether DateAndTime represents local wall clock time, or location-independent time. I think that it needs to represent location-independent time, and that we should define it as such. The instance variables in DateAndTime make this a bit obscure, but if the value of the absolute time and the value of the local time zone offset are kept separate, it becomes less confusing. That is what I tried to do in http://wiki.squeak.org/squeak/6197
I did not remove the timezone handling in Locale startup yet, although it is useless now.
- Bert -
This looks good to me.
I like the automatic time zone offset update in DateAndTime>>now.
For primPosixMicrosecondClockWithOffset, we probably should have fallback code that calls <primitive 135> primMillisecondClock for VMs that support only the original millisecond clock primitive.
Dave