Tim Rowledge <tim at sumeru.stanford.edu> wrote:
> Why return munged up seconds when quite often the image code
> immediately works backwards to derive the day/hour/year etc? Let's pass
> the prim a sensible date/time object aand fill in the
> year/day/hour/minute/second/mSec/flavour-of-the-day-icecream etc. No
> need to worry about epoch stuff. Leave the OS to care about timezone,
> DST.
> 

Sure, that sounds a little better.  I've actually impremented this
primitive once each way at this point, and found them to be about the
same, but sure, why insist on computation that is not necessary?

To clarify one subthread of the discussion, I did not mean that the
primitive should return a true mungification algorithm, but rather
should return the UTC time plus the local time -- or equivalently, local
time plus a delta to get to UTC time.  If we really go crazy, optionally
let the VM stick a string in there to describe the time zone being used,
e.g. "EST".

And oh yeah, you may as well report at least milliseconds while you are
at it, though it seems we may as well go with microseconds to be safe. 
Judging from history, this primitive is very slow to change, so the next
version is likely to last a long time--quite possible long enough that
sub-millisecond timing makes sense in Squeak.


Finally, there really is benefit to giving the image a little info about
what is going on with the timezones, even if for many uses all you want
is a reasonable rendering of local time.  With the primitive as I
described it:

1. Apps that, by "time", really mean "time", can use the UTC time and
stay sane.  This is important, for example, if a messages comes over the
network saying "initiate the transfer at 4:00pm on October 1, 2004". 
4:00pm where??

1b. If you care about leap seconds, you know you are using real UTC (to
the best the computer can provide it), and you can procede as well as
you ever can with UTC.

2. Internet apps can compute correct strings such as this one:

	Date: Mon, 27 Sep 2004 18:30:51 +1200 (NZST)

Note that this is neither a local time nor a UTC time, but a combination
thereof.

3. A timezone-savvy image can do all of its own mungification under the
user's prefered timezone setting.  It just uses the "UTC" and "timezone
string" fields that the VM provides, and then does everything else
itself.


This interface seems to make all the simple things be simple, and it
seems to make the complex things as easy as they ever are.



-Lex


PS -- i would never trust my computer's flavor of the day, but yours may
have better taste