Hi,
DOMINIQUE TRONCHE via GNU coreutils Bug Reports <[email protected]>
writes:
> We encountered a bug using the program date when the time zone is configured
> with Chamorro Standard Time (Pacific/Guam or Pacific/Saipan)
> The command date itself displays the date properly:
> #ln -s /usr/share/zoneinfo/Pacific/Guam /etc/localtime
> #date
> Thu Mar 26 00:30:09 ChST 2026
>
> However, when used with -d option, an error message is returned
> # date -d "$(date)" '+%s'
> date: invalid date 'Thu Mar 26 00:30:16 ChST 2026'
Thank you for the report.
However, it is not a bug and is a result of date format ambiguities. The
parser used by 'date' has very limited support for time zone
abbreviations because they are highly ambiguous. For example, a person
from India and a person from Ireland will use IST to refer to two very
different time zones. Likewise, a person from the United States and a
person from Australia will use EST to refer to different time zones.
I suggest using 'date --iso-8601=seconds', which avoids those
ambiguities when sharing dates with others. It can also be parsed
correctly, which it looks like you were trying to do:
$ date -d "$(date --iso-8601=minutes)"
Wed Mar 25 10:46:00 PM PDT 2026
Another issue with the command you shared is that localized dates cannot
be parsed correctly:
$ LC_ALL=zh_CN.UTF-8 date
2026年 03月 25日 星期三 22:48:11 PDT
Ignoring character differences, it would be very difficult to parse all
the different date formats used by each locale.
Collin
