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