On Mon 2008-02-11T13:31:17 +0000, Tony Finch hath writ: > How should the kernel interpret time stamps stored in filesystems? Do you > propose to retrospectively re-interpret them as being in TI instead of > POSIX time? (This is related to the problem that Unixes have with FAT > filesystems that store timestamps in some unspecified local time, which > implies that the kernel can't be ignorant of local time.)
I suggest that the question of retrospective time stamps is not interesting, for it is rarely possible to be sure that a system clock was set "correctly", and it is never possible to convince history to revise its notion of what time it thought it was (today is George Washington's birthday, O.S.). The interoperational scenario of POSIX systems, Windows systems, NTP, and anything else which is making an effort to maintain filesystem timestamp synchrony deserves closer analysis. > How do you cope with programs that assume that POSIX time is UTC, and > which therefore bypass the tz code when handling UTC timestamps? My impression is that if TI is internationally endorsed (BIPM has already indicated openly that if UTC were to abandon leaps they might consider abandoning TAI) then it is mostly a change in documentation to say that such codes will henceforth be handling the international standard TI instead of the other international standard UTC. > How do you represent TI textually? i.e. how should ISO 8601 be revised? Given that the ephemerides all started making plain distinction between time scales starting in the year I was born I'm flabbergasted to note that ISO 8601 did not already face this issue. Plainly the IAU's long-time recommendations that the time scale be explicit belong in ISO 8601. Until then TI will not be representable. > How does this affect NTP, which uses a POSIX-like timescale? My impression was that NTP already has more than enough complexity to handle the situation. It already has a monotonic time scale which can tolerate leaps, but is distinct from any civil or scientific standard therefore requiring a formatting or conversion to other operational time scales. My point in this whole exercise is basically admitting that in a world of machine-assisted telecommunications the underlying operational time scale need be monotonic. In such a world mean solar time is equally conventional with daylight/summer time shifts. > Surely its work on the ITRF is still needed for satellite navigation. Agreed, but somehow I get the impression that will not catch the attention of legislators and bureaucrats nearly as well as pointing out that their earth rotation measurements directly affect how they set their watches. I expect the IERS would lose a lot of visibility and political clout without leap seconds. -- Steve Allen <[EMAIL PROTECTED]> WGS-84 (GPS) UCO/Lick Observatory Natural Sciences II, Room 165 Lat +36.99855 University of California Voice: +1 831 459 3046 Lng -122.06015 Santa Cruz, CA 95064 http://www.ucolick.org/~sla/ Hgt +250 m _______________________________________________ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs