* Russ Allbery [2006-03-14 09:46:30 -0800]: > Jim Rees <[EMAIL PROTECTED]> writes: > > > It looks like this is the only format vos -time understands. Can anyone > > think of a reason not to fix this? > > Not I. YYYY-MM-DD is generally the best date format to use, since I think > it's unambiguous in pretty much every country. It should be fairly easy > to add it as another recognized date form, I would think.
It's called ISO 8601 in some circles. Definitely worth supporting, including the suggestion to use (in this case, accept as input) a capital T as the separator between the date and the time part. Saves some quoting/escaping trouble in the shell. Marcus Kuhn has a nice page at http://www.cl.cam.ac.uk/~mgk25/iso-time.html . In my view, the main shortcoming of the current code is not the MM/DD vs. DD/MM "ambiguity" but the impossibility to specify the timezone. "Local time" is a fuzzy concept when AFS cells can span continents, not to mention those one-hour discontinuities twice a year at a time of night when backups are in progress. I'd rather use UTC; a very minimal enhancement to the current code would be to recognise a final Z as meaning that. 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. _______________________________________________ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
