Zefram is not on the time zone mailing list; direct replies appropriately. --ado -----Original Message----- From: Zefram [mailto:zefram@fysh.org] Sent: Friday, May 19, 2006 12:30 PM To: tz@lecserver.nci.nih.gov Subject: timezones offset from what? I've been doing work on precision timekeeping on computer systems. Naturally I don't use timezones at all inside that code, but there are places where I need to apply timezones when presenting a time to non-specialist humans. Looking through the zoneinfo database and the theory written about it, it struck me that although it deals fantastically with what time offset to use, there's no rigorous treatment of what base time scale to apply the offset to. Then it struck me that a simple treatment of this could solve a couple of other issues with the database. An example of this issue: as the zoneinfo source notes, UK legal time is currently based on mean solar time on the Greenwich meridian. Now that's not even Universal Time any more, since the prime meridian moved (slightly) off the Greenwich meridian. But everyone in the UK in practice sets their clocks based on UTC, as promulgated by the NPL and the BBC. At centisecond timescales, GMT (legal time in the UK), UTC (used in practice), UT1 (which UTC tracks in the long term), and UT2 (used for civil time in the 1950s) are all quite distinct. So I have a suggestion: it would be nice if the zoneinfo database included a field identifying exactly which time scale to apply the offsets to. The database doesn't need to understand how the time scales relate to each other; leave that to the precision horologists. All it needs is a short text string, with values such as "UTC", "UT1", "GMT". Of course, in a lot of cases this information is unavailable, or the distinction wasn't being made, so you'd then give "UT" to be explicitly ambiguous about the exact flavour of Universal Time. This field would also allow the database to handle timezones that are based on something other than UT. Currently the data files for Saudi Arabia attempt to describe apparent solar time in terms of UT, by means of a daily offset change. But it could instead be specified as a fixed offset with a base of apparent solar time on the prime meridian. To understand the zone properly the code would need to calculate the equation of time, but that only needs to be implemented once and it would give a much smoother and more accurate result than the daily UT offset changes do. A system that doesn't do the equation of time would effectively fall back to mean solar time, which is what the Riyadh8X zones do anyway. It's also a way to handle Mars time. Just specify the base to be MTC instead of UT. Ta da. What do you think? -zefram
"Olson, Arthur David \(NIH/NCI\) [E]" <olsona@dc37a.nci.nih.gov> writes:
From: Zefram [mailto:zefram@fysh.org] Sent: Friday, May 19, 2006 12:30 PM
there's no rigorous treatment of what base time scale to apply the offset to.
In the current implementation, the base time scale is always UTC, usually with leap seconds skipped, but leap second support is there if you want it. Hence UK times are de facto (modulo leap seconds), not de jure. I suppose there might be more-advanced applications where most Unix processes wants to use a UTC-based time scale, but one process wants to use a GMT-based one (or UT1, or Mars solar time, etc.). But that sounds pretty specialized. It shouldn't be needed for civil times anywhere on the planet, so it'd probably be an astronomical application or something like that. 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. There's a similar issue for support for other calendars, e.g., the Persian calendar in widespread use in Iran.
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
Zefram <zefram@fysh.org> writes:
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.
True. I had forgotten about that.
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.
I don't know of any application that requires that. I can easily construct theoretical legal scenarios where the problem might come up, but in practice I don't think it's ever a real problem that actually requires writing software. (If I'm wrong, I'd like to see the counterexample....) For example, legal time in Britain is defined in terms of GMT, but GMT itself is no longer defined as a standard, and hasn't been for decades. So if you wanted to argue that some legal event occurred (say) on May 15 GMT but May 14 UTC, you'd have an uphill battle.
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.
Rather like the time zone database, too. The topics are intimately connected, since part of the time zone database is derived directly from the Persian calendar. If Iran brings back DST, then we'll have the same problem again, of lack of long-term predictability.
Have you developed any theory yet for what will happen with Martian timezones?
Nope. Each landed mission on Mars has adopted a completely different reference for time keeping. I figure that we'll see a half dozen or more systems before things settle down enough to develop a "theory". In the mean time I'm willing to defer to Mars24 guys.
participants (3)
-
Olson, Arthur David (NIH/NCI) [E] -
Paul Eggert -
Zefram