Re: Mechanism to provide tai-utc.dat locally
On 27 Dec 2006 at 20:57, John Cowan wrote: > Very true. And adopting the Egyptian-Roman calendar redefined > the concept of a "month". Somehow civilization survived. Keeping months in sync with phases of the moon apparently turned out to be insufficiently important to civilization to require it as a feature of the calendar. I'm doubtful that keeping clocks in approximate sync with the rising and setting of the sun is likely to be judged equally unimportant, however. -- == Dan == Dan's Mail Format Site: http://mailformat.dan.info/ Dan's Web Tips: http://webtips.dan.info/ Dan's Domain Site: http://domains.dan.info/
Re: Mechanism to provide tai-utc.dat locally
Rob Seaman scripsit: > Mucking with leap seconds is equivalent to redefining the > concept of a "day". Very true. And adopting the Egyptian-Roman calendar redefined the concept of a "month". Somehow civilization survived. -- John Cowan [EMAIL PROTECTED] http://ccil.org/~cowan I must confess that I have very little notion of what [s. 4 of the British Trade Marks Act, 1938] is intended to convey, and particularly the sentence of 253 words, as I make them, which constitutes sub-section 1. I doubt if the entire statute book could be successfully searched for a sentence of equal length which is of more fuliginous obscurity. --MacKinnon LJ, 1940
Re: Mechanism to provide tai-utc.dat locally
On Dec 27, 2006, at 14:32, Poul-Henning Kamp wrote: It's impossible to accurately represent a millisecond using binary fractions. That would be unacceptable for most sub-second use. Reality check: with a 32bit fraction, the error would be 69 ps. ...which accumulates in arithmetic and causes equality comparisons to fail. This should hold: 1000 * 1ms == 1s It won't if you use a binary fraction. A better idea might have been to use Haskell's "Rational" type for 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. Yes, let us make it as expensive as possible to operate on timestamps, so that everybody will have to invent their own faster type. NOT! I'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
In message <[EMAIL PROTECTED]>, Ashley Yakeley writes: >On Dec 27, 2006, at 06:29, Poul-Henning Kamp wrote: > >> That's a pretty bad format. Computers are binary and having >> pseudo-decimal fields like tv_usec in timeval, tv_nsec in timespec >> and picoseconds in Haskell is both inefficient and stupid. >> >> The fractional part should be a binary field, so that the width >> can be adjusted to whatever precision and wordsize is relevant. > >It's impossible to accurately represent a millisecond using binary >fractions. That would be unacceptable for most sub-second use. Reality check: with a 32bit fraction, the error would be 69 ps. >A better idea might have been to use Haskell's "Rational" type for >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. Yes, let us make it as expensive as possible to operate on timestamps, so that everybody will have to invent their own faster type. NOT! -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.
Re: Mechanism to provide tai-utc.dat locally
In message: <[EMAIL PROTECTED]> Ashley Yakeley <[EMAIL PROTECTED]> writes: : On Dec 27, 2006, at 06:29, Poul-Henning Kamp wrote: : : > That's a pretty bad format. Computers are binary and having : > pseudo-decimal fields like tv_usec in timeval, tv_nsec in timespec : > and picoseconds in Haskell is both inefficient and stupid. : > : > The fractional part should be a binary field, so that the width : > can be adjusted to whatever precision and wordsize is relevant. : : It's impossible to accurately represent a millisecond using binary : fractions. That would be unacceptable for most sub-second use. Ummm, it is possible to represent sub-picoseconds accurately using binary fractions. what are you talking about? Warner
Re: Mechanism to provide tai-utc.dat locally
On Dec 27, 2006, at 06:29, Poul-Henning Kamp wrote: That's a pretty bad format. Computers are binary and having pseudo-decimal fields like tv_usec in timeval, tv_nsec in timespec and picoseconds in Haskell is both inefficient and stupid. The fractional part should be a binary field, so that the width can be adjusted to whatever precision and wordsize is relevant. It's impossible to accurately represent a millisecond using binary fractions. That would be unacceptable for most sub-second use. A better idea might have been to use Haskell's "Rational" type for 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
Zefram scripsit: > In the general case: to determine or use an interval of N calendar FOOs, > it is convenient to represent the time as a linear count of calendar > FOOs plus details of the exact position within the current FOO. FOO may > be minute, hour, day, week, month, or year. I think there should be > record formats for all of these cases (the native UTC format is one > of these with FOO = day), with conversion functions between them and > also a linear count of seconds. That's overkill. If we confine ourselves to the Gregorian calendar, a time interval can be safely represented as a triple of months, minutes, and seconds. All time units longer than a month contain a fixed and integral number of months, and all time units larger than a minute and smaller than a month contain a fixed and integral number of minutes. (If we don't care about leap seconds, shock horror, we can just use months and seconds.) -- The man that wanders far[EMAIL PROTECTED] from the walking tree http://www.ccil.org/~cowan --first line of a non-existent poem by: John Cowan
Re: Mechanism to provide tai-utc.dat locally
Clive D.W. Feather writes:
WG14 is willing in principle to make changes to time_t, up to and
including
completely replacing it by something else. *BUT* it needs a
complete and
consistent proposal and, preferably, experience with it.
This is at the heart of my distaste for the so-called leap hour
proposal. There is no coherent proposal, no implementation plan, no
discussion of adverse effects, no budget, no collection of pertinent
use cases, no exploration of requirements - no technical design
discussion at all.
Meanwhile, the astronomical community (like other prudent
communities, presumably) has instituted long range planning efforts
like the U.S. Decadal Surveys. Major (and minor) telescope and
instrumentation projects involve multi-year design commitments with
significant budgets of their own simply to develop coherent and
complete proposals to submit to the funding agencies. The U.S.
national centers have recently been subject to an NSF Senior Review
process that is likely to have a major affect on all our operating
budgets to free up funding for new initiatives. No pain, no gain.
On the other hand, we have a "proposal" to change the fundamental
underpinnings of world-wide civil timekeeping. A (publicly
unavailable) proposal that can't even be bothered to suggest how DUT1
will be conveyed in a future in which this quantity would assume
vastly greater importance. It's an embarrassment.
Any proposal has got to deal with a whole load of issues, many of
which
haven't been properly documented. For example, it should be
possible to add
and subtract times and intervals (e.g. "what time is 14 months and
87 days
from now?").
Poul-Henning Kamp wrote:
... which is exactly the kind of thing you can not do with any
{origin+offset} format, due to leap seconds.
Leap seconds are an effect, not a cause. The intrinsic difficulty is
with mapping interval time to Earth orientation (mean solar time).
Whatever mechanism is used to synchronize civil time to the sun -
including embargoing leap seconds as leap hours - there will always
be this complication.
Consider an ISO 8601 compliant date/time representation, e.g.:
% date -u +"%FT%TZ"
2006-12-27T16:47:27Z
The first part is the (Gregorian) calendar date - the second clearly
represents a fraction of a day. From my point of view, this is the
beginning and end of the argument establishing an identity between
civil time and mean solar time. Others are willing to permit a slow
secular drift - in the calendar, too, of course, not just in the
clock. Mucking with leap seconds is equivalent to redefining the
concept of a "day".
The point is that over a long enough period, a broad enough temporal
horizon, we all agree that civil time must be synchronized to solar
time. The emergence of the absurd leap hour proposal from among
folks who loathe leaps of any sort demonstrates that. They weren't
eager to center their notional position around leap hours - rather,
they felt obligated. In short, there is no escaping the need to
grapple with the fundamental distinction between Earth orientation
and "atomic" interval counts. Just as, as one enlarges ones spatial
horizon one cannot fail to run into relativistic effects.
Timekeeping is a subtle business. Others on this list surely
understand that better than I.
Rob Seaman
NOAO
Re: Mechanism to provide tai-utc.dat locally
In message <[EMAIL PROTECTED]>, Zefram writes: >Ashley Yakeley wrote: >>In the Haskell time library, I represent UTC time by what seemed to >>me the simplest possible correct type. This is a record containing an >>integer to represent day number (as MJD), and a fixed-point decimal >>(picosecond resolution) to represent seconds since midnight. The >>allowed range for this is 0 to 86400.. > >That's a pretty good format. That's a pretty bad format. Computers are binary and having pseudo-decimal fields like tv_usec in timeval, tv_nsec in timespec and picoseconds in Haskell is both inefficient and stupid. The fractional part should be a binary field, so that the width can be adjusted to whatever precision and wordsize is relevant. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.
Re: Mechanism to provide tai-utc.dat locally
On Wed, 27 Dec 2006, Zefram wrote: > > Your principle is probably correct; I'm just saying that the > implementation you're thinking of doesn't actually satisfy the criterion. When you quoted me you snipped the bit where I said "its implementation is far from ideal". This is not just because of the update problem: the whole library is built around time_t and the traditional time API both of which are hopeless. Tony. -- f.a.n.finch <[EMAIL PROTECTED]> http://dotat.at/ NORTH UTSIRE SOUTH UTSIRE: WEST OR NORTHWEST 3 OR 4, OCCASIONALLY 5. SLIGHT. FAIR. MODERATE OR GOOD.
Re: Mechanism to provide tai-utc.dat locally
Tony Finch wrote: >I was thinking partly from the point of view of infrastructure: if you >have a mechanism that can keep the system's timezone database up-to-date, >then it is adequate for keeping the leap second table up-to-date. The Olsen software has a built-in assumption that the timezone database never changes. After loading timezone data from disk it never checks to see if it's changed, so it'll miss any change that was announced after the program started running. I don't think that's adequate for leap second data. I'm pretty unhappy about it for timezone data too. The Perl DateTime::TimeZone code, based on the Olsen database, similarly doesn't handle updates: the data is compiled to Perl code. DateTime::LeapSecond compiles the leap second table as Perl code, suffering the same problem. Your principle is probably correct; I'm just saying that the implementation you're thinking of doesn't actually satisfy the criterion. -zefram
Re: Mechanism to provide tai-utc.dat locally
Ashley Yakeley wrote: >On Dec 27, 2006, at 01:23, Clive D.W. Feather wrote: >>Any proposal has got to deal with a whole load of issues, many of which >>haven't been properly documented. For example, it should be possible to add >>and subtract times and intervals (e.g. "what time is 14 months and 87 days >>from now?"). It should also be possible to say "what time is 10^7 seconds from now?". To do arithmetic with all these units requires several different representations of time. >In the Haskell time library, I represent UTC time by what seemed to >me the simplest possible correct type. This is a record containing an >integer to represent day number (as MJD), and a fixed-point decimal >(picosecond resolution) to represent seconds since midnight. The >allowed range for this is 0 to 86400.. That's a pretty good format. >call to get the current UTC time relies on gettimeofday, so it is >unavoidably off by up to a second during a leap-second insertion. It's possible to fix this up by using ntp_adjtime(3). This gives the Unix time (except on some systems where it doesn't and you have to use ntp_gettime(3) for that bit) plus a state variable from the leap second system. See my Perl module Time::UTC::Now for the logic required to decode it. >Therefore I have the concept of "nominal UTC difference". For >instance, between 2005-12-31 23:00 UTC and 2006-01-01 01:00 UTC there >were two hours and one second of time, but only two hours of nominal >UTC time. This is essentially a calendar difference. In that range you have exactly two calendar hours, one of which is 3601 s long. It's just like saying that the interval between 2006-01-01T00Z and 2006-03-01T00Z is two (calendar) months, where the two months are of different lengths. In the general case: to determine or use an interval of N calendar FOOs, it is convenient to represent the time as a linear count of calendar FOOs plus details of the exact position within the current FOO. FOO may be minute, hour, day, week, month, or year. I think there should be record formats for all of these cases (the native UTC format is one of these with FOO = day), with conversion functions between them and also a linear count of seconds. Then the user of the API can do eir own arithmetic on the linear counts. -zefram
Re: Mechanism to provide tai-utc.dat locally
On Dec 27, 2006, at 01:23, Clive D.W. Feather wrote: POSIX in the past deferred to WG14 (the ISO C committee) because that's where time_t came from. WG14 is willing in principle to make changes to time_t, up to and including completely replacing it by something else. *BUT* it needs a complete and consistent proposal and, preferably, experience with it. Any proposal has got to deal with a whole load of issues, many of which haven't been properly documented. For example, it should be possible to add and subtract times and intervals (e.g. "what time is 14 months and 87 days from now?"). Well, I can explain what I did in Haskell, at least. In the Haskell time library, I represent UTC time by what seemed to me the simplest possible correct type. This is a record containing an integer to represent day number (as MJD), and a fixed-point decimal (picosecond resolution) to represent seconds since midnight. The allowed range for this is 0 to 86400.. Thus, time during a leap second can at least be unambiguously represented. However, my call to get the current UTC time relies on gettimeofday, so it is unavoidably off by up to a second during a leap-second insertion. The majority of users of my library do not want to know about TAI or leap-seconds, but cannot tolerate unexpected off-by-one-second issues. Therefore I have the concept of "nominal UTC difference". For instance, between 2005-12-31 23:00 UTC and 2006-01-01 01:00 UTC there were two hours and one second of time, but only two hours of nominal UTC time. It's incumbent upon anyone using "nominal UTC difference" that they understand its flaw in representing time, if they care. This is easy in Haskell, since it has a different type from the type I provide for real time difference, and these cannot substitute for each other. -- Ashley Yakeley
Re: Mechanism to provide tai-utc.dat locally
On Dec 26, 2006, at 23:02, M. Warner Losh wrote: Of course, needing to know TAI-UTC offsets leads one to interesting situations. What does one do if one has TAI time, but not UTC and a conversion is asked for? If it's a time in the future rather than just the current time, the thread 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
In message <[EMAIL PROTECTED]>, "Clive D.W. Feather
" writes:
>M. Warner Losh said:
>WG14 is willing in principle to make changes to time_t, up to and including
>completely replacing it by something else. *BUT* it needs a complete and
>consistent proposal and, preferably, experience with it.
>
>Any proposal has got to deal with a whole load of issues, many of which
>haven't been properly documented. For example, it should be possible to add
>and subtract times and intervals (e.g. "what time is 14 months and 87 days
>from now?").
... which is exactly the kind of thing you can not do with any
{origin+offset} format, due to leap seconds.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
Re: Mechanism to provide tai-utc.dat locally
M. Warner Losh said: > time_t is so totally broken, it isn't funny. That's the closest thing > to a standardized API there is for time. All others are stuff folks > have done here or there, but they aren't universal enough to be > considered. > > Too bad the problems with time_t are well known, well discussed and > well enumerated. Or rather I should say "too bad POSIX doesn't care > enough to change it" since the cost of changing time_t is huge... Not so. POSIX in the past deferred to WG14 (the ISO C committee) because that's where time_t came from. WG14 is willing in principle to make changes to time_t, up to and including completely replacing it by something else. *BUT* it needs a complete and consistent proposal and, preferably, experience with it. Any proposal has got to deal with a whole load of issues, many of which haven't been properly documented. For example, it should be possible to add and subtract times and intervals (e.g. "what time is 14 months and 87 days from now?"). -- Clive D.W. Feather | Work: <[EMAIL PROTECTED]> | Tel:+44 20 8495 6138 Internet Expert | Home: <[EMAIL PROTECTED]> | Fax:+44 870 051 9937 Demon Internet | WWW: http://www.davros.org | Mobile: +44 7973 377646 THUS plc||
