Sergio Gelato <[EMAIL PROTECTED]> 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 ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/> _______________________________________________ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info