In message <9275.852269194@munnari.OZ.AU>, Robert Elz wrote:
We go even one step further and remove the redundant minute offset digits
The minutes offset is certainly not redundant. I find it hard to believe that anyone who knows anything about time zones can believe that. In Australia right now there are two different time zones that are not even hours. +1030 and +0930.
I am very well aware of 30 min offsets. You probably have not read my full proposal (sorry, perhaps some parts of the discussion didn't go to tz). Here is the proposal again shown by examples (all show the same time): 1996-12-31 15:08:32-05 the common case 1997-01-01 01:38:32+05:30 very rare 30-min offsets 1996-12-31 20:08:32Z UTC 1996-12-31 15:08:32.048-05 higher precision for applications with 1996-12-31 20:08:32.05Z many timestamps per second 1997-01-01 01:38:32.048123456+05:30 worst case length: 35 characters I find these very nice, practical, and readable. For instance, GNU RCS 5.7 (with option -zLT, in the next revision hopefully by default) does it already right: $Id: tamper.html,v 1.8 1996-12-03 00:35:29-05 kuhn Rel $ So I am not inventing a new format here, but just suggest to use proven technology. Add "setenv RCSINIT -zLT" to your Unix startup scripts and enjoy the new date format with RCS 5.7 or higher. Another note: For maximum interoperability, the number of second fraction digits after the dot should be limited to 9 by the standard. This gives the nanosecond precision offered by the POSIX 1003.1b timer library functions, and I doubt anyone will ever need higher timing precision here. Just a guideline for dimensioning buffers and fgets() cutoff limits. About my comment on the RFC822 date format: Yes, I fully appreciate that they didn't use "5:12 p.m. 7/8/96", as I have seen it in another proprietary system recently. Things always could be worse ... ;-) Markus -- Markus G. Kuhn, Computer Science grad student, Purdue University, Indiana, USA -- email: kuhn@cs.purdue.edu