TZ=EDT date reporting misleading times

Bug #1452314 reported by Dan McGrath
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
coreutils (Ubuntu)
New
Undecided
Unassigned

Bug Description

While working in a UTC system I stumbled upon some oddities with the date command, that at least appear to differ from how BSD systems report (correctly) when EDT or gibberish is passed to date via the TZ env variable.

Currently I am in EST timezone, which during daylight savings time, is EDT. If I run date with "TZ=", I get changes in timezones used by date as expected, but noticed that EDT was actually returning UTC time, but displays "EDT" (so 10am becomes 2pm) despite actually displaying UTC.

As a test, I also tried supply a bunch of gibberish only to find that BSD actually replaces the gibberish with the text "UTC", while linux systems just spit back the same gibberish (ie: TZ=jhsdjflhljak date), but report it in UTC time. So in the case where a user supplies a valid timezone such as EDT, one can make time related mistakes as linux will actually report UTC but use the label the user supplied. What is worse, is that Ubuntu actually shows my current time zone as "EDT" yet it isn't recognized as a valid zone!

Here are some same outputs to clarify the problem on linux and bsd:

Freebsd:
[dan@barley ~]$ TZ=UTC date
Wed May 6 15:09:26 UTC 2015
[dan@barley ~]$ TZ=EST date
Wed May 6 10:09:32 EST 2015
[dan@barley ~]$ TZ=EDT date
Wed May 6 15:09:39 UTC 2015
[dan@barley ~]$ TZ=lkjhsd date
Wed May 6 15:11:16 UTC 2015 <==== good, correctly informs me what its reporting

Ubuntu 14.04:
dan@wks:~$ TZ=UTC date
Wed May 6 15:10:48 UTC 2015
dan@wks:~$ TZ=EST date
Wed May 6 10:10:48 EST 2015
dan@wks:~$ TZ=EDT date
Wed May 6 15:10:48 EDT 2015 <==== EDT = UTC?!
dan@wks:~$ date
Wed May 6 11:10:56 EDT 2015 <==== the real EDT time
dan@wks:~$ TZ=lkjhsd date
Wed May 6 15:11:30 lkjhsd 2015 <===== wth?

ProblemType: Bug
DistroRelease: Ubuntu 14.04
Package: coreutils 8.21-1ubuntu5.1
ProcVersionSignature: Ubuntu 3.13.0-46.79-generic 3.13.11-ckt15
Uname: Linux 3.13.0-46-generic x86_64
NonfreeKernelModules: nvidia
ApportVersion: 2.14.1-0ubuntu3.10
Architecture: amd64
CurrentDesktop: XFCE
Date: Wed May 6 11:01:37 2015
InstallationDate: Installed on 2014-06-11 (329 days ago)
InstallationMedia: Xubuntu 14.04 LTS "Trusty Tahr" - Release amd64 (20140416.2)
SourcePackage: coreutils
UpgradeStatus: No upgrade log present (probably fresh install)

Revision history for this message
Dan McGrath (troubled) wrote :
Revision history for this message
Dan McGrath (troubled) wrote :

Just to clarify, the problem with TZ=EDT isn't that it reports EDT wrong, per se, but that any unrecognized time zones show as UTC. Now, why TZ=EDT isn't valid when `date` on its own here reports EDT just fine, is beyond me :)

Revision history for this message
Ard van Breemen (ard) wrote :

I can confirm that this is still the case...
On an ubuntu 20.04:
```
ard@lenny:~$ TZ=US/Eastern date
Mon Mar 29 09:08:43 EDT 2021
ard@lenny:~$ TZ=America/New_York date
Mon Mar 29 09:08:47 EDT 2021
ard@lenny:~$ TZ=EDT date
Mon Mar 29 13:08:51 EDT 2021
ard@lenny:~$ TZ=EST date
Mon Mar 29 08:16:16 EST 2021
ard@lenny:~$ TZ=NNN date
Mon Mar 29 13:16:26 NNN 2021
ard@lenny:~$ TZ=NNNN date
Mon Mar 29 13:16:31 NNNN 2021
```
on trusty:
```
ard@trusty:~$ TZ=EDT date
Mon Mar 29 13:17:27 EDT 2021
ard@trusty:~$ TZ=US/Eastern date
Mon Mar 29 09:17:38 EDT 2021
ard@trusty:~$ TZ=EST date
Mon Mar 29 08:17:45 EST 2021
ard@trusty:~$ TZ=NNNN date
Mon Mar 29 13:17:51 NNNN 2021
ard@trusty:~$ TZ=America/New_York date
Mon Mar 29 09:18:27 EDT 2021
ard@trusty:~$ TZ=xxx date
Mon Mar 29 13:18:46 xxx 2021
ard@trusty:~$ TZ=xxxxxxx date
Mon Mar 29 13:18:50 xxxxxxx 2021
ard@trusty:~$ TZ=CET date
Mon Mar 29 15:19:30 CEST 2021
ard@trusty:~$ TZ=CEST date
Mon Mar 29 13:19:34 CEST 2021
ard@trusty:~$ TZ=UTC date
Mon Mar 29 13:21:31 UTC 2021

```

So timezone setting using the name EDT are broken. The only way to get EDT is to use US/Eastern or America/New_York .
Personally I think it's a bug to not accept EDT (might be ambiguous), and an even bigger bug to just echo the TZ if the TZ is actually unknown.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.