FW: timezones offset from what?

Zefram zefram at fysh.org
Mon May 22 20:35:15 UTC 2006

Paul Eggert wrote:
>In the current implementation, the base time scale is always UTC,

Yes, except that UTC didn't exist before 1961.  I reckon that Unix time
prior to NTP is best understood as representing an unspecified form
of UT, rather than anything so specific.  (I wrote about this in the
Wikipedia article on Unix time.)  The timezone database seems to have
the same slightly-fuzzy semantics, because it presumes a base of UTC
in the current era but also has data for historical eras where not only
UTC but even UT was not defined.

>                            It shouldn't be needed for civil times
>anywhere on the planet,

I think it is, where legal time is required with sub-second precision.
Sub-second precision is a somewhat specialised requirement, but getting
less so.

>                                     If someone wanted to do that, I'd
>like to see their implementation before worrying about adding support
>for it to the tz code or database.

Fair enough.  For what I'm doing, btw, having the data in the database
source files is more useful to me than making the tz code handle it.
I'm not using time_t or localtime() and that crowd, because of the
limited precision and the leap seconds issue.  I'm working primarily
in Perl.  I wrote Time::UTC and Time::UTC::Now, which exist to handle
UTC correctly (leap seconds and all) with arbitrary precision.  My data
type of choice is Math::BigRat, a bignum rational format.  I have a
clock program which uses Time::UTC::Now and also gets timezone offsets
from the tz database via DateTime::TimeZone: it ticks correctly through
leap seconds, displaying in an arbitrary timezone.

>There's a similar issue for support for other calendars, e.g., the
>Persian calendar in widespread use in Iran.

This is an interesting philosophical question.  The Persian calendar
particularly is troublesome because it's an observational calendar,
where the month start isn't known until it actually happens.  You'd
need to download new calendar data every month, and you can't do date
calculations more than a few days ahead.  Rather like leap seconds.
But aside from that, I think choice of calendar is out of scope for the
timezone database.

I think the proper action of the timezone system is to turn an absolute
point in time into a time of day plus an abstract day identity.  The day
identity would be best represented as a Chronological Julian Day Number
(linear count of days, days start at midnight in timezone of choice).
We currently in practice use the Gregorian calendar instead of a CJDN,
but I think we should view this use of the Gregorian calendar as an
interchange format, rather than as a forced choice of calendar.  How this
abstract day identity gets communicated to the user is a user interface
issue, possibly a localisation issue, but it's not a timezone issue.

Mars is a different kind of complication.  Where I referred to a "point in
time" I really refer to a point on some particular time axis.  On Earth
the time axis we use is that of Terrestrial Time (see Wikipedia), but
under relativity there are other meaningful ones too.  Serious timekeeping
on Mars, once there are atomic clocks there, would define a Martian Time
scale, so the starting point for telling the time is a fundamentally
different quantity.  Furthermore, Mars days don't correspond to Earth
days, so they need to be numbered on a different scale.  (There are a
couple of sol numbering schemes.)  A timezone specified as an offset
from MTC implicitly brings in this different time axis and day scale
by reference.

There's more than one proposed calendar for Mars, but there we're back
to a localisation issue.  I think the timezone issue is that a Martian
timezone refers to a different set of days from those that a Terran
timezone does.

Have you developed any theory yet for what will happen with Martian


More information about the tz mailing list