[OpenAFS] vos: failed to parse date...

[Russ Allbery]

Sergio Gelato <Sergio.Gelato@astro.su.se> writes:

[...]
> I also second the suggestion of accepting seconds since the UNIX epoch:
> it's what AFS uses internally, including in the dump file format. If one
> wants to base the start time for an incremental dump on the time of a
> previous dump (which is stored in that dump's header) one shouldn't have
> to go through strftime() and strptime().

> That's probably enough formats. It may be elegant to also accept TAI
> timestamps, but I think most people can live without that. Don't try 
> to guess whether the user meant DD/MM/YY or MM/DD/YY.

Okay, so let's get some consensus on what we're going to implement before
anyone writes code.  It sounds like what people want are:

 * The current date format.
 * yyyy-mm-dd
 * yyyy-mm-dd hh:mm[:ss][-/+zzzz]
 * yyyy-mm-ddThh:mm[:ss][-/+zzzz]
 * yyyy-mm-dd hh:mm[:ss]Z
 * yyyy-mm-ddThh:mm[:ss]Z
 * Seconds since epoch.

Where ZZZZ is the numeric time zone offset in hours and minutes *not*
number of minutes.

I think a reasonable implementation strategy would be to add an
afs_strptime that either calls the system strptime if available or cobbles
something up from BSD-licensed source if not and tries each of the above
time variations in sequence.  This should be fairly easy to implement, and
since I don't think parsing ASCII timestamps is a critical path in code
anywhere, it should be as simple as just having a table of strptime
formats and walking through them all.

An alternate approach would be to write a quick ISO 8601 date parser
(which actually accepts a few other variations on the above) and try the
current format and then it and then Unix timestamp.  That would be more
work, but ISO 8601 date parsers may already be available for free.

Then we just have to find everywhere that takes a time and call the
appropriate function.

-- 
Russ Allbery (rra@stanford.edu)             <http://www.eyrie.org/~eagle/>