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