On Thursday 03 February 2005 18:42, Marcin 'Qrczak' Kowalczyk wrote:

"Udo Stenzel" writes:

...

Therefore, TAI + calendar + (optional) a fixed offset.

What am I missing?

That you don't know the correct offset.

If a program begins miscalculating the time when it's run 6 months after the Haskell compiler it was compiled with was been updated, and thus programs compiled using different versions of the compiler interpret the same timestamp differently, this makes no sense.

No problem if the leap second table used is a parameter of the conversion. Ben -- "The CIA is Wallstreet. Wallstreet is the CIA." (Mike Ruppert)

Marcin 'Qrczak' Kowalczyk wrote:

You shift the responsibility without eliminating the problem. The program begins miscalculating the time when it's run 6 months after its author has updated the leap second table which the program uses.

Of course it's impossible to solve it. This means that conversion between TAI and UTC should be avoided when possible.

If the user wants to obtain UTC, doesn't mind a hiccup on leap seconds, and doesn't want to keep a leap second table up to date and arrange for a long-running program to reread it when it changes - he can set the system clock to UTC and the program should then interpret the system clock as UTC.

Why doesnt the library connect to one of the TAI clocks, and read the leap second table. If the system clock is UTC the system must be running NTP and be connected to a network. If it is not running NTP the system time is more or less TAI anyway (no leap seconds occur without a networked time reference and NTP) I would suggest having the library read the leap seconds table as part of the library, as leap seconds can only occur at the end of june or december, you have 6th months to update the table. Keean.

Ashley Yakeley wrote:

I think even people who don't use NTP set their clock to UTC at the time they set it. You can call that TAI with a fixed offset if you want (and an offset we can't discover), but the difference is probably less significant than the clock drift, and in the long term they'll likely eventually set it to UTC again.

SO in effect what you are saying is that system time is likely to be neither TAI nor UTC (as hand setting a clock has a greater than 1 second error usually, a non-networked machine will never tell the right time (and even a stopped clock tells the right time twice a day!). If the machine is not networked then its time cannot be compared to other time sources, so absolute time is meaningless... as such we are left with relative time (which is TAI like as it counts seconds from switch on). If I am timing an interval measured in seconds, I do not want the user changing the 'calendar time' to affect my accurate timings. I am pretty sure the "clock()" function returns a millisecond count, which added to the hardware time at switch on (as the user cannot adjust time when the machine is switched off - nor can NTP adjust this) gives TAI (possibly with a different start time). Keean.

On 2005-02-04, Ashley Yakeley wrote:

In article <42035F4E.6000104@imperial.ac.uk>, Keean Schupke wrote:

...

SO in effect what you are saying is that system time is likely to be neither TAI nor UTC (as hand setting a clock has a greater than 1 second error usually, a non-networked machine will never tell the right time (and even a stopped clock tells the right time twice a day!).

Can we make that assumption? There might be ways of keeping the clock accurate that don't involve TCP/IP.

Right. The NTP source code has plenty of other things that can by synced off of, including many fairly common GPS receivers, and radio clocks. -- Aaron Denney -><-

On Sat, Feb 05, 2005 at 09:33:20AM +0000, Keean Schupke wrote:

Aaron Denney wrote:

...

Right. The NTP source code has plenty of other things that can by synced off of, including many fairly common GPS receivers, and radio clocks.

Does this mean I can sync my system time to TAI using a GPS reciever? Sounds like how it should be done...

Yes. look at the various "refclock"s in the distribution. Note that as mentioned a few times on this list, getting everything to agree on the interpretation may be difficult, though using the set of timezones labeled "right" will go far. -- Aaron Denney -><-

In article <83fcd29a8070c7a77db3b2f01bbaac71@comcast.net>, Gregory Wright wrote:

Raw GPS time (the number of seconds since the GPS epoch) is broadcast in a complicated form in the satellites' navigation message, along with the current number of UTC leap seconds since the GPS epoch. From the raw GPS time and the number of leap seconds UTC can be calculated.

So there's some way that the satellites get told about leap seconds when they're announced? -- Ashley Yakeley, Seattle WA

Keean Schupke writes:

If the machine is not networked then its time cannot be compared to other time sources, so absolute time is meaningless...

It's still meaningful that filesystem timestamps are interpreted by Haskell programs in the same way as by other programs. Even if the current time as measured by the system might be disconnected from the reality and off by a few seconds, it's internally consistent across programs. Without network connection we know the intended UTC of timestamps, i.e. how the second counter should be converted to calendar time for display, even if this actually happened some time after or before the given time. We don't know TAI because we don't necessarily have an up to date leap second table. If there is a way to support TAI without disrupting the interpretation of the time on systems which use UTC everywhere, then it's fine by me.

I am pretty sure the "clock()" function returns a millisecond count, which added to the hardware time at switch on

No, it measures CPU time of the current process with an unspecified point of reference (usually the first clock() call). If the process is waiting for I/O, its clock doesn't tick. On systems with 32-bit clock_t it rolls over after 72 minutes. POSIX says that CLOCKS_PER_SEC should be 1000000, no matter what the actual clock accuracy is. clock() is useful for comparing performance of algorithms, even if there are other processes competing for the CPU. It doesn't completely eliminate their influence on the measurement though - if many other processes are running, less data fits in processor cache. -- __("< Marcin Kowalczyk \__/ qrczak@knm.org.pl ^^ http://qrnik.knm.org.pl/~qrczak/