-00:00 on draft-newman-datetime-00.txt

[Markus G. Kuhn]

In message <9275.852269194 at 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 at cs.purdue.edu