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 timezones? -zefram