Re: Unifying Atomic Time and the post-Gregorian calendar corrections
On Thu 2003-07-03T18:30:00 +0100, Markus Kuhn hath writ:
Thanks for pointing this out! Weekday-continuity is indeed a bit of a
problem of this approach. I can't see any other practical solution than
skipping one weekday together with the skipped 29 February 5600, in
other words, 5600-03-01 would be a Wednesday also in all the local
civilian time zones.
It also deserves to be pointed out that the Julian Date would not
match in the two different calendrical schemes. With that it becomes
tricky to calculate elapsed time.
But then, they didn't have computer software to worry about during any
of the past calendar reforms. I think user requirements might have
changed for weekdays.
Are you willing to risk a fatwah if this is implemented and you are
identified as the one who proposed that a Friday will eventually
disappear from the calendar?
According to
http://www.tondering.dk/claus/cal/node3.html#SECTION00322000
astronomers such as John Herschel (1792-1871) and others suggested in
the past to augment the Gregorian calendar with a rule that makes every
year divisible by 4000 not a leap year. Similarly, the Orthodox church
in Greece considered in the 1920s to replace the Gregorian Y mod 400 =
0 rule with a Y mod 900 in {200, 600} rule. I'd be curious to hear,
whether the usefulness of such proposals have ever been discussed more
recently in the light of modern astrometric and orbital-modeling
capabilities. Or do we first have to build a vast solar-system wide
equivalent of GPS to gather data about the solar gravitation and
pressure environment with sufficient accuracy for long-term forecasting?
Read the reference near the bottom of my Future of UTC page:
http://catless.ncl.ac.uk/Risks/17.86.html#subj10
Newcomb's mean longitude of the sun includes terms which naively
appear to be secular but which are actually the leading wave of
periodic changes. That is why they should not be used even now, let
alone a long time from now. Herschel did not have access to anywhere
near as many or as accurate a set of obsesrvations as Newcomb did.
There is no way to take Herschel's long term prediction for the
calendar seriously.
The deceleration of earth rotation is a secular term which we can be
sure will affect civil time. On the contrary, I would be very
surprised to find anyone who would seriously contend that there are
any secular changes of the earth's orbit or obliquity which are
predictable enough to justify complicating the SRG's business.
Nevertheless, I'll ask around just to be more sure.
--
Steve Allen UCO/Lick Observatory Santa Cruz, CA 95064
[EMAIL PROTECTED] Voice: +1 831 459 3046 http://www.ucolick.org/~sla
PGP: 1024/E46978C5 F6 78 D1 10 62 94 8F 2E49 89 0E FE 26 B4 14 93
Re: making leap hours workable
Title: RE: [LEAPSECS] making leap hours workable I believe you would get very strong pushback from the POSIX world if you tried to make the time base TAI rather than UTC. Without a strong case for this change (which I haven't seen yet), I would be one of them. /glen -Original Message- From: Steve Allen [mailto:[EMAIL PROTECTED]] Sent: July 2, 2003 5:04 PM To: [EMAIL PROTECTED] Subject: Re: [LEAPSECS] making leap hours workable On Wed 2003-07-02T15:45:44 -0400, Seeds, Glen hath writ: From: Steve Allen [mailto:[EMAIL PROTECTED]] Unlike the POSIX timestamping community which has buried its head in the sand and refused to admit that time_t should be TAI, any form of TI must be uniformly incrementing forever. There are several inaccuracies in this statement. The POSIX timestamping community has already had many long discussions of these issues. The current state of the standard reflects several realities. I stand by the tense of my statement: time_t *should* be TAI in order that POSIX timestamps can be unambiguous and monotonically increasing. I fully recognize the realities that prevent it from being TAI. And I applaud the POSIX Real Time folks for taking the broader view which, when fully implemented, will permit compatibility with existing usage as well as monotonicity. The notion of DUTH in my proposal is the safety valve which permits leap seconds to be ignored for 500 years while still demanding that there be a mechanism which will handle the longer term problems. If such a DUTH scheme were implemented it might still be that posterity would decide never to increment it, but at least they would have the option built into the systems of the world. sign me Waiting (but not holding my breath) for the SRG to take the same sort of broader view with respect to civil time and broadcast time signals. -- Steve Allen UCO/Lick Observatory Santa Cruz, CA 95064 [EMAIL PROTECTED] Voice: +1 831 459 3046 http://www.ucolick.org/~sla PGP: 1024/E46978C5 F6 78 D1 10 62 94 8F 2E 49 89 0E FE 26 B4 14 93 This message may contain privileged and/or confidential information. If you have received this e-mail in error or are not the intended recipient, you may not use, copy, disseminate or distribute it; do not open any attachments, delete it immediately from your system and notify the sender promptly by e-mail that you have done so. Thank you. Join us at Cognos' biggest event of the year Enterprise 2003, The Cognos Business Forum. Taking place in over 25 cities around the world, it's an opportunity for Business and IT leaders to learn about strategies for driving performance. Visit www.cognos.com/enterprise03 for more details.
Re: making leap hours workable
Title: RE: [LEAPSECS] making leap hours workable -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: July 2, 2003 4:32 PM To: [EMAIL PROTECTED] Subject: Re: [LEAPSECS] making leap hours workable The second reality is that many existing applications depend on calculations that assume that time_t has exactly 86400 seconds per year. (Note that it does NOT follow from this that there are 86400 POSIX seconds in any given calendar year. ... Obviously you mean per day. Yes - sorry for the typo. UTC+TZ is the only readily available precise measure of local time, so mandating TAI would conflict with this. I beg to differ on your use of precise measure. Nothing in POSIX requires time (local, time_t, etc.) to be precise. I don't disagree. However, there are some POSIX users with such a requirement. Correct me if I am wrong, but: Timezones in POSIX are defined as offsets of the UTC timezone (sic) as P1003.1 once called it. Names of points in time within the UTC timezone are computed from those seconds since the Epoch timestamp / time_t values. Nothing in POSIX, as far as I can see, says that PST8PDT has anything to do with UTC, local standard time, TAI, etc. It is a 8 hour offset from that UTC timezone which related to those seconds since the Epoch timestamp values / time_t values. And as you point out: POSIX implementors and application writers ... have no control over whether time_t is TAI, UTC, or anything else. This is under the control of the system owners and operators, and the host environment that the POSIX implementation is embedded in. ... the time_t can be anything ... including TAI, UTC, a bogus clock, etc. * So time_t can be related to almost anything. * The POSIX TZ=UTC names computed from those seconds since the Epoch time_t timestamp values can therefore related to almost anything. * Timezones such as PST8PDT are 8 hours off of POSIX TZ=UTC, can therefore related to almost anything. And thus the claim of mandating TAI would conflict with this appears to be false. =-= I am not commenting on the value/wisdom of mandating TAI. But from my reading of POSIX, it appears that there is no POSIX conflict in mandating TAI. chongo () /\oo/\ =-= Yes and no. This is a slippery area, as we all know. Here's the exact wording (from the most recent published version of POSIX's current incarnation - the Single UNIX Specification: The expanded format (for all TZs whose value does not have a colon as the first character) is as follows: stdoffset[dst[offset][,start[/time],end[/time]]] ... offset Indicates the value added to the local time to arrive at Coordinated Universal Time. The offset has the form: hh[:mm[:ss]] It's clear from this wording that the INTENT her is for time base to actually be UTC. How well that intent maps to reality is (as already mentioned), not under direct POSIX control. However, deliberate use of TAI as a base, rather than UTC, would clearly violate this intent. /glen This message may contain privileged and/or confidential information. If you have received this e-mail in error or are not the intended recipient, you may not use, copy, disseminate or distribute it; do not open any attachments, delete it immediately from your system and notify the sender promptly by e-mail that you have done so. Thank you. Join us at Cognos' biggest event of the year Enterprise 2003, The Cognos Business Forum. Taking place in over 25 cities around the world, it's an opportunity for Business and IT leaders to learn about strategies for driving performance. Visit www.cognos.com/enterprise03 for more details.
