Issue
While attempting to parse AWS log filenames with embedded timestamps, I ran across the following
$ date --version
date (GNU coreutils) 8.30
Copyright (C) 2018 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <https://gnu.org/licenses/gpl.html>.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Written by David MacKenzie
$ realpath /etc/localtime
/usr/share/zoneinfo/America/New_York
$ echo $TZ
$ date --utc --date='20211114T0155Z' --debug
date: parsed number part: (Y-M-D) 2021-11-14
date: parsed zone part: UTC+07
date: parsed number part: 01:55:00
date: parsed zone part:
date: input timezone: parsed date/time string (+00)
date: error: seen multiple time-zone parts
date: invalid date ‘20211114T0155Z’
While talking with co-workers (in multiple timezones), it appears that some shells may find a timezone of UTC-07 instead of my (WSL2 Ubuntu) UTC+7 regardless of actual timezone. This may be either due to OSX specifically or do to a version difference (my OSX coworkers appear to have date version 9 while I'm running 8.3).
I've looked through info date and haven't found anything that looks like it explains this. On the contrary, Section 29.5 contains the following:
The ISO 8601 date and time of day extended format consists of an ISO 8601 date, a ‘T’ character separator, and an ISO 8601 time of day. This format is also recognized if the ‘T’ is replaced by a space
Despite this section saying a T is equivalent to a space, this does not appear to be true:
$ date --utc --date='20211114T0155Z'
date: invalid date ‘20211114T0155Z’
$ date --utc --date='20211114 0155Z'
Sun Nov 14 01:55:00 UTC 2021
Solution
I believe this boils down to the heuristic being used in parse-datetime is determining that this is in military time instead of ISO 8601 basic format.
I haven't traced through all of parse-datetime yet, but I believe the difference in sign of the "phantom timezone" between date versions 8.3 and 9 is coming from gnulib#5c438e8 and that seems like fairly strong evidence that this is what is happening. Additionally, without being familiar with this library at all, it seems reasonable that this parser section may be generating this phantom timezone specifically.
This feels like a bug in the parse-datetime implementation, but for now I feel like my curiosity is appeased.
I'll leave this question open for a while longer in case someone with more experience has a better answer, which I'd accept over this at any point, now or in the future.
Answered By - nivekastoreth