time zones, offtopic (Was: Various fixes for Celeste)

Eric Ulevik eau at fast.fujitsu.com.au
Tue Dec 7 04:52:03 UTC 1999


From: Stan Heckman <stan at stanheckman.com>
> "Eric Ulevik" <eau at fast.fujitsu.com.au> writes:
> > Time is not overly complicated, but it's not as simple as most
programmers
> > think. The key is to use a sensible basis for measurement (eg. UTC).
Perform
> > all your calculations using this basis, and treat everything else as
> > labelling rules (eg. local time).
>
> Sounds good. Most of the code around here stays in GPS or TAI as long
> as possible before converting to UTC, but that's because of the
> FORTRAN and C programmers' prejudice for subtraction instead of method
> calls. Smalltalk helps us here; Smalltalkers expect time to be an
> object, not a long integer, so no one would complain were time offsets
> computed with method calls that consulted the leap second table.

Agreed. Hopefully, in practice, leap seconds could be added later.

> A problem with UTC is historical dates. The number of seconds per year
> was not measured before the 60's, and (I think) the extra seconds were
> not assigned to particular days until the 70's.

See ftp://maia.usno.navy.mil/ser7/tai-utc.dat for a table assigning all leap
seconds.

> If we were to keep your strategy of using a sensible basis for
> measurement and treating historical calendars as labelling rules, we
> could use either ephemeris time or Julian day numbers as the sensible
> basis. Unfortunately, these have the problem of not being convertible
> to UTC.

These are convertible. Easiest way is to use Terrestial Time.

> For me, this *is* overly complicated.  Lex has shown that a very
> simple solution exists if we ignore both leap seconds and historical
> dates. I suspect that we could include either one of these with a
> bearable increase in complexity, but I doubt enough users would care
> for either feature to justify the extra code. And I can't think of any
> solution that includes both leap seconds and historical dates that is
> not excessively complex. So I like Lex's solution.
>
> But maybe someone has a bright idea for how to make leap seconds and
> historical dates simple?

Not really... leap seconds are fiddly. But I think they could be ignored in
an initial implementation.

I think ignoring historical dates would be a pity. An initial implementation
could just support the propleptic Gregorian caldendar. Other calendars could
be added later.

Regards,

Eric Ulevik





More information about the Squeak-dev mailing list