On Fri, Jan 11, 2013 at 08:56:05PM -0800, tim Rowledge wrote:
> 
> On 11-01-2013, at 6:04 PM, "David T. Lewis" <lewis at mail.msen.com> wrote:
> > 
> > 
> > The underlying problem behind all this is that early Squeak VMs reported system
> > time in the local time zone rather than UTC, which may have made sense at the
> > time for single-user systems but is a mess if you want to do any kind of reasonable
> > time zone support or calculation of time durations. I'd love to throw the whole
> > thing out and start over with UTC throughout, but needless to say that would be
> > a non-trivial amount of work.
> 
> 
> The weird thing is that my code for ioSeconds() hasn't changed since '96 and I lived in California back then and in fact on the Wet Coast ever since 91. I don't recall ever having the time not be correct and I worked on that machine every damn day. The only story I can think of that makes any sense of it would involve RISC OS not having timezone support when I moved from the UK, me keeping the machine on PST and never taking advantage of timezone support when it arrived. I suppose it's possible.
> 
> Whatever, I guess I'll TZ ioSeconds() for now and be done with it!
> 

Um ... I'm a little confused myself at this point, I'm not sure what
has changed here. But I'm quite confident that in practice ioSeconds()
has been answering seconds from the "Smalltalk epoch" relative to local
time zone for a many years (probably since the first Squeak VMs). I put
that in quotes because it turns out that the Squeak definition of
Smalltalk epoch is just plain wrong. It should be this:

  DateAndTime epoch ==> 1901-01-01T00:00:00-00:00

Not this:

  DateAndTime epoch ==> 1901-01-01T00:00:00-05:00

(I am in Michigan USA, offset 5 hours from UTC)

I'll note for the record that there are now primitives that do answer
time based on UTC offset, so if you can implement ioUtcWithOffset() you
will have these:

primitiveUtcWithOffset
	"Answer an array with UTC microseconds since the Posix epoch and
	the current seconds offset from GMT in the local time zone.
	This is a named (not numbered) primitive in the null module (ie the VM)"

primitiveUTCMicrosecondClock
	"Answer the UTC microseconds since the Smalltalk epoch. The value is
	derived from the Posix epoch (see primitiveUTCMicrosecondClock) with a
	constant offset corresponding to elapsed microseconds between the two
	epochs according to RFC 868."

The first is an atomic call to obtain current time and offset relative to
Posix epoch, and the second answers seconds from the Smalltalk epoch, where
Smalltalk epoch is understood to be relative to GMT.

Dave