Re: Introduction of long term scheduling

2007-01-08 Thread Ashley Yakeley
ry of measurements"). But apparently not? Are the satellite clocks allowed to drift, or do they get corrected? -- Ashley Yakeley

Re: Introduction of long term scheduling

2007-01-06 Thread Ashley Yakeley
know have been enumerated elsewhere... Presumably it only needs to know the next leap-second to do this, not the whole known table? -- Ashley Yakeley

Re: Introduction of long term scheduling

2007-01-06 Thread Ashley Yakeley
tahoe Don't forget " | one second off since 2018". :-) -- Ashley Yakeley

Re: Introduction of long term scheduling

2007-01-06 Thread Ashley Yakeley
On Jan 6, 2007, at 13:47, Poul-Henning Kamp wrote: In message <[EMAIL PROTECTED]>, Ashley Yakeley writes: On Jan 6, 2007, at 11:36, Poul-Henning Kamp wrote: B. i) Issue leapseconds with at least twenty times longer notice. This plan might not be so good from a software engin

Re: Introduction of long term scheduling

2007-01-06 Thread Ashley Yakeley
emand maximum speed. That's sensible for a simple timestamp, but trying to squeeze in a leap-second table probably isn't such a good idea. -- Ashley Yakeley

Re: Introduction of long term scheduling

2007-01-06 Thread Ashley Yakeley
ten years later with the first unexpected leap second. At least with the present system, programmers are (more) forced to face the reality of the unpredictability of the time-scale. -- Ashley Yakeley

Re: Introduction of long term scheduling

2007-01-05 Thread Ashley Yakeley
line for MJD of expiration date, and each subsequent line with the MJD of the start of the offset period, a tab, and then the UTC-TAI seconds difference. That said, my notion of UTC is restricted to the step- wise bit after 1972, and others might want more information. -- Ashley Yakeley

Re: A lurker surfaces

2007-01-02 Thread Ashley Yakeley
what you wrote. Eh, GPS time is TAI. You just have to know about the odd encoding... -- Ashley Yakeley

Re: A lurker surfaces

2007-01-02 Thread Ashley Yakeley
versa. That's not the case for UTC, since you don't know what the leap second offset will be if it's too far in the future. Of course you can also extract UTC from a GPS signal. -- Ashley Yakeley

Re: A lurker surfaces

2007-01-02 Thread Ashley Yakeley
adio. So, sure, there's an infrastructure cost for a sensible time of day... > ntpd is UTC, by definition. I wonder how easily NTP could be generalised to transmit different timescales without too much confusion? Using different UDP port numbers might be one option. -- Ashley Yakeley

Re: A lurker surfaces

2007-01-02 Thread Ashley Yakeley
tions that need it. -- Ashley Yakeley

Re: A lurker surfaces

2007-01-02 Thread Ashley Yakeley
y) 60 kHz carrier that must still have exactly 6 cycles per SI second. The obvious solution is to transmit rubber time on a rubber frequency. -- Ashley Yakeley

Re: A lurker surfaces

2007-01-02 Thread Ashley Yakeley
earth orientation parameters, btw? -- Ashley Yakeley

Re: A lurker surfaces

2007-01-01 Thread Ashley Yakeley
t to everyone else, the second is a fraction of the day. -- Ashley Yakeley

Re: A lurker surfaces

2007-01-01 Thread Ashley Yakeley
other week, or whatever. Software should serve human needs, not the other way around. Anyone needing fixed seconds should use TAI. Actually I was going to suggest that everyone observe local apparent time, and include location instead of time-zone, but I think that would make communication annoying. -- Ashley Yakeley

Re: Mechanism to provide tai-utc.dat locally

2006-12-27 Thread Ashley Yakeley
7;m not seeing the problem here: you can represent an integer in the range 0 to 86400 with a 64-bit type. There's nothing faster than integer arithmetic. -- Ashley Yakeley

Re: Mechanism to provide tai-utc.dat locally

2006-12-27 Thread Ashley Yakeley
the seconds offset, which is stored as two integers (for numerator and denominator). Instead I used a fixed-point type (internally just an integer from 0 to 86400). It does not separate "integer" and "decimal" part. -- Ashley Yakeley

Re: Mechanism to provide tai-utc.dat locally

2006-12-27 Thread Ashley Yakeley
de for real time difference, and these cannot substitute for each other. -- Ashley Yakeley

Re: Mechanism to provide tai-utc.dat locally

2006-12-27 Thread Ashley Yakeley
d may have to block for years... Probably you'd want a "quick" function that returns a special "don't know" value, or throws exception, or returns a special result code (as COM). Then the caller can decide what to do. -- Ashley Yakeley

Re: Mechanism to provide tai-utc.dat locally

2006-12-26 Thread Ashley Yakeley
s Windows XP and Ubuntu). The alternative to my idea is to have a leap-seconds file as a software package that will be updated every six months. -- Ashley Yakeley

Re: Mechanism to provide tai-utc.dat locally

2006-12-25 Thread Ashley Yakeley
t.gov/pub/leap-seconds.list> Some other files I've found: <ftp://oceans.gsfc.nasa.gov/COMMON/leapsec.dat> <ftp://oceans.gsfc.nasa.gov/COMMON/utcpole.dat> -- Ashley Yakeley

Re: Mechanism to provide tai-utc.dat locally

2006-12-25 Thread Ashley Yakeley
ookup just to retrieve two bytes. And if you want to find out when transitions are, you need to make repeated lookups. -- Ashley Yakeley

Re: Mechanism to provide tai-utc.dat locally

2006-12-25 Thread Ashley Yakeley
idn't know that. My Ubuntu box does indeed have that. My Mac OS X box has the "zoneinfo" tz database, but does not have a "right" directory in it, for some reason. -- Ashley Yakeley, Seattle WA

Mechanism to provide tai-utc.dat locally

2006-12-24 Thread Ashley Yakeley
lement their own mechanism. Does this strike people as worthwhile? Does anyone know of an existing effort along these lines? Thanks, -- Ashley Yakeley Seattle WA