On 5/24/09 8:32 AM, "Bob Paddock" <bob.paddock@gmail.com> wrote: >> A 33.31 format would buy us a century, still allow us to get >> nanoseconds right, but it be computationally inconvenient and >> looks messy, so people balk at it. > > Anything wrong with TAI64NA? > > http://cr.yp.to/libtai.html > > "libtai is a library for storing and manipulating dates and times. > > libtai supports two time scales: (1) TAI64, covering a few hundred > billion years with 1-second precision; (2) TAI64NA, covering the same > period with 1-attosecond precision. Both scales are defined in terms > of TAI, the current international real time standard. " > > TAI64NA in FPGA? > Of course...buried in the install notes "But keep in mind that this is a very early release. Some of the code hasn't been tested at all! " As of 1998... It also breaks the time up into seconds, nanoseconds, and attoseconds, as separate chunks, so math isn't trivial struct taia { struct tai sec; unsigned long nano; /* 0...999999999 */ unsigned long atto; /* 0...999999999 */ } ; I don't think this library buys you a whole lot (other than useful routines to do things like calculate easter or leap days/seconds), but at the basic "how does one keep time" level, not particularly an improvement. Also, someone I was discussing this with at work reminded me of a common problem. We often run tests in a testbed where we need to have the entire testbed running at some time *not the actual time*.. E.g. If you're simulating a Mars entry,descent,landing scenario, you want the spacecraft running with "time" at the expected EDL time. But, you want to have everybody sync'd to a common source. So, it's easy to get all the computers controlling the test gear sync'd to UTC or TAI using something like NTP, but you need a way to have precision "simulated time" as well.

In message <C63EC123.7F8B%James.P.Lux@jpl.nasa.gov>, "Lux, James P" writes: >> Anything wrong with TAI64NA? >> >> http://cr.yp.to/libtai.html >> >It also breaks the time up into seconds, nanoseconds, and attoseconds, as >separate chunks, so math isn't trivial >I don't think this library buys you a whole lot [...] I dont' think it buys you anything, except trouble. It is a perfect example of what I said earlier: people cannot grasp that time do not come in parcels... -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.

In message: <C63EC123.7F8B%James.P.Lux@jpl.nasa.gov> "Lux, James P" <james.p.lux@jpl.nasa.gov> writes: : : : : On 5/24/09 8:32 AM, "Bob Paddock" <bob.paddock@gmail.com> wrote: : : >> A 33.31 format would buy us a century, still allow us to get : >> nanoseconds right, but it be computationally inconvenient and : >> looks messy, so people balk at it. : > : > Anything wrong with TAI64NA? : > : > http://cr.yp.to/libtai.html : > : > "libtai is a library for storing and manipulating dates and times. : > : > libtai supports two time scales: (1) TAI64, covering a few hundred : > billion years with 1-second precision; (2) TAI64NA, covering the same : > period with 1-attosecond precision. Both scales are defined in terms : > of TAI, the current international real time standard. " : > : > TAI64NA in FPGA? : > : : Of course...buried in the install notes : : "But keep in mind that this is a very early release. Some of : the code hasn't been tested at all! " : : As of 1998... : : It also breaks the time up into seconds, nanoseconds, and attoseconds, as : separate chunks, so math isn't trivial : : struct taia { : struct tai sec; : unsigned long nano; /* 0...999999999 */ : unsigned long atto; /* 0...999999999 */ : } ; : : : I don't think this library buys you a whole lot (other than useful routines : to do things like calculate easter or leap days/seconds), but at the basic : "how does one keep time" level, not particularly an improvement. : : : Also, someone I was discussing this with at work reminded me of a common : problem. We often run tests in a testbed where we need to have the entire : testbed running at some time *not the actual time*.. E.g. If you're : simulating a Mars entry,descent,landing scenario, you want the spacecraft : running with "time" at the expected EDL time. But, you want to have : everybody sync'd to a common source. : : So, it's easy to get all the computers controlling the test gear sync'd to : UTC or TAI using something like NTP, but you need a way to have precision : "simulated time" as well. We did something akin to this at a previous employer. On the whole, we found that math was more compute intensive than the fractional method that phk recommends, but that the presentation to the user was easier with this break down. We opted to stick with this breakdown. The other problem you run into is that you're often given a time in UTC time, but need to operate on TAI time so that you kick something every second and aren't affected by leap seconds. There are many other time scales that are in use that you can get data from as well. Plus many different conventions for dealing with things (like an fractional MJD: is that always computed with / 86400 or do you use /86401 on positive leap days?) All these details can be a pita to get right and belong in a base library. So libtai can work in theory, but we found we had to add a lot to it. Warner

Some (Penrose, Nottale) suggest that time may be discrete rather than continuous. Though 10E-43 second might be difficult to measure. Poul-Henning Kamp wrote: > > It is a perfect example of what I said earlier: people cannot grasp > that time do not come in parcels... > > >