J.T. Conklin wrote:
> First some background.
>
> The continuous integration build framework I maintain at work uses
> timestamp files for "last_build", "last_success", etc. The contents
> of each file is the timestamp in ISO 8601 format (the inode mtime is
> set to the same value, but thats besides the point).
>
> I used this format thinking that the 'T' separator between date and
> time would be more resistant to errors (shell quoting, etc.) than a
> format that used spaces.
>
> But someone reported that coreutils' date's -d option could not parse
> this format. Fortunately, date -r could be used; but this challenges
> my idea that the ISO format is more useful.
>
> I've done some tweaks to parse-datetime.y as shown. Since 'T' now can
> be either a millitary-style single character timezone and a separator,
> I've special cased it as a token in the lexer. With the changes, the
> function can parse the ISO 8601 / RFC 3339 YYYY-MM-DDTHH:MM:DD+MMSS
> format (but not other valid ISO 8601 formats that omit -'s and :'s).
> This adds another grammar conflict, but the parse-getdate test suite
> still executes correctly.
>
> I'm interested in comments on both the idea of supporting such time
> formats, and whether there is a better implementation.
Thank you! This patch looks fine.
As Paul mentioned, a complete change would be welcome,
if you can fill out paperwork. Considering that you already
have several assignments on file, you must know the routine,
but here's a link anyway:
http://git.sv.gnu.org/cgit/coreutils.git/tree/HACKING#n429
If you currently cannot assign copyright, your patch is just small
enough (even with your other recent "tiny" change) to squeak by without one.
