Re: Introduction of long term scheduling

2007-01-05 Thread Tony Finch
On Thu, 4 Jan 2007, Michael Deckers wrote: This leads me to my question: would it be helpful for POSIX implementors if each and every UTC timestamp came with the corresponding value of DTAI attached (instead of DUT1)? Would this even obviate the need for a leap seconds table? No,

Re: Introduction of long term scheduling

2007-01-05 Thread Rob Seaman
Tony Finch wrote: you need to be able to manipulate representations of times other than the present, so you need a full leap second table. Which raises the question of how concisely one can express a leap second table. Leap second tables are simply a list of dates - in ISO 8601 or MJD

Re: Introduction of long term scheduling

2007-01-05 Thread Steve Allen
On Fri 2007-01-05T21:14:19 -0700, Rob Seaman hath writ: Which raises the question of how concisely one can express a leap second table. Gosh, Rob, I remember toggling in the boot program and starting up the paper tape reader or the 12-inch floppy disc drive, but now I'm not really sure I

Re: Introduction of long term scheduling

2007-01-05 Thread Ashley Yakeley
On Jan 5, 2007, at 20:14, Rob Seaman wrote: An ISO string is really overkill, MJD can fit into an unsigned short for the next few decades This isn't really a good idea. Most data formats have been moving away from the compact towards more verbose, from binary to text to XML. There are good

Re: Introduction of long term scheduling

2007-01-05 Thread Rob Seaman
Ashley Yakeley wrote: As the author of a library that consumes leap-second tables, my ideal format would look something like this: a text file with first 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