On Tue, Feb 16, 2016 at 10:05:06PM -0600, Chris Muller wrote:
> 
> On Tue, Feb 16, 2016 at 1:00 PM, tim Rowledge <tim at rowledge.org> wrote:
> >
> >> On 15-02-2016, at 7:17 PM, Chris Muller <asqueaker at gmail.com> wrote:
> >>
> >> Date today and DateAndTime now are reporting tomorrow's date instead
> >> of today's.  Ouch!
> >>
> >> DateAndTime now   " 2016-02-16T03:16:25.421108-06:00"
> >>
> >> That's my timezone offset.  But its still Monday, the 15th, not the 16th..
> >>
> > Hmph. Checking on my Pi I get a completely wrong TZ because my preference
> >  ???useLocale??? is false. The code in Locale>startUp: dates back to 2005/8
> > so it???s unlikely to be wrong without having been noticed.
> >
> > Hmm, even weirder - it???s not a preference I screwed up so far as I can
> > tell since it is the same in a plain 5.0 image on my iMac. Which makes me
> > wonder why the menubar time is correct???
> >
> > Oh yuck. DateAndTime>now uses nowWithOffset: and the (wrong) offset. The
> > ClockMorph uses Time>now which works from millisecondsSinceMidnight and
> > uses the old prim 135 millisecond clock in an original 5.0 image and
> > localMicrosecondClock in a recent update. So the TZ is getting added at
> > the primitive level and we have confusion. Is it really a good idea to
> > have a primitive using the OS idea of TZ as well as image code using its
> > own idea of TZ?
> >
> > The net effect with latest updates installed is -
> > DateAndTime now 2016-02-16T18:56:54.67808+01:00
> > Time now 10:56:51.64374 am
> >
> >
> The problem has nothing to do with timezones or offsets.  Those
> haven't changed in several years.  Try printing "Date today" in a
> Squeak 5.0 release image, then update it to latest trunk, and print it
> again.  They don't match.
> 
> I think this is probably related to the new utcMicrosecond clock stuff.
>

Well this is a fine kettle of fish (http://www.phrases.org.uk/meanings/kettle-of-fish.html).

At first glance, the problem seems to be that with the UTC time changes,
'DateAndTime now' requires a time zone. If you enable preference #useLocale,
the system is supposed to figure out a time zone from 'Locale current'.
That in turn depends on the LocalPlugin, which does seem to be present.

But I see that the primitive methods in Local are working, so the
uninitialized instance vars are a red herring, which I will toss into the
kettle of fish for later consideration.

As a workaround, I was going to suggest setting the TimeZone class variable
in DateAndTime to something that represents your local time zone offset.
For me, this would be:

DateAndTime localTimeZone: (TimeZone
	offset: -4 hours
	name: 'Eastern Daylight Time'
	abbreviation: 'EDT')

But it looked like that the offset is bass-ackwards, so I did this instead:

DateAndTime localTimeZone: (TimeZone
	offset: 4 hours
	name: 'Eastern Daylight Time'
	abbreviation: 'EDT')

Oops, that that does not work either. Apparently the time zone offset is
going into the bit bucket.

It seems that we currently have a mashup of things in Chronology that
assume that the system reports time in local wall clock time (which is
and always has been horrible), plus recent updates that do some things
in location-independent UTC (good, but not yet working right).

I will post an update to DataAndTime class>>nowWithOffset that seems to
me to be the LHTTCPW (least horrible thing that could possibly work).

Dave