Bug 1411150

Summary:	PST timezone data problem with PST
Product:	Red Hat Enterprise Linux 7	Reporter:	tin.ho
Component:	glibc	Assignee:	glibc team <glibc-bugzilla>
Status:	CLOSED NOTABUG	QA Contact:	qe-baseos-tools-bugs
Severity:	medium	Docs Contact:
Priority:	unspecified
Version:	7.5-Alt	CC:	ashankar, codonell, fweimer, mnewsome, pfrankli
Target Milestone:	rc
Target Release:	---
Hardware:	x86_64
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2017-07-20 07:30:14 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description tin.ho 2017-01-08 20:49:43 UTC

Description of problem:
There is some quickiness with the timezone data with PST.
The date command and output of ls -l would not show correct time when TZ is set to PST, but works with America/Los_Angeles.  EST works fine.  But PST seems to be the default and thus has downstream problems.  eg when running inside container such as singularity and docker


Version-Release number of selected component (if applicable):
RHEL 5.x
RHEL 6.x
RHEL 7.x



How reproducible:
100%



Steps to Reproduce:

Method A:
date -d "TZ=\"PST\" 2014-03-01 14:47:14"


Method B:
docker run...  
export TZ=PST
date


Method C:
singularity shell ...
date




Actual results:



Method A, TZ in date command:

$ date
Sat Mar  1 14:47:14 PST 2014

# PST below shows incorrect time:
$ date -d "TZ=\"PST\" 2014-03-01 14:47:14"
Sat Mar  1 06:47:14 PST 2014

$ date -d "TZ=\"PT\" 2014-03-01 14:47:14"
Sat Mar  1 06:47:14 PST 2014

$ date -d "TZ=\"PST8PDT\" 2014-03-01 14:47:14"
Sat Mar  1 14:47:14 PST 2014

$ date -d "TZ=\"EST" 2014-03-01 17:47:14"
Sat Mar  1 14:47:14 PST 2014


Method B, TZ and date inside docker container environment:


sn@backbay:/home/Docker$ date
Sun Jan  8 11:59:04 PST 2017

sn@backbay:/home/Docker$ docker run -i -t --rm centos:7
[root@a49a190c11af /]# date
Sun Jan  8 19:59:27 UTC 2017
[root@a49a190c11af /]# echo $TZ

# setting timezone to PST to get date return incorrect result:
[root@a49a190c11af /]# export TZ=PST; date
Sun Jan  8 19:59:56 PST 2017
[root@a49a190c11af /]# export TZ=America/Los_Angeles; date
Sun Jan  8 12:00:06 PST 2017

[root@a49a190c11af /]# export TZ=EST; date
Sun Jan  8 15:00:13 EST 2017
[root@a49a190c11af /]# export TZ=America/New_York; date
Sun Jan  8 15:00:23 EST 2017


NOTE: Used CentOS image as I didn't see an official RHEL image in docker hub


Method C, TZ and date inside singularity container environment:



# below is the correct, expected time:
sn@backbay:/opt/singularity_repo$ date
Sun Jan  8 12:38:49 PST 2017
sn@backbay:/opt/singularity_repo$ echo $TZ

sn@backbay:/opt/singularity_repo$ 


# but inside the container, the default time, even stated as PST, is wrong:
sn@backbay:/opt/singularity_repo$ /opt/tmp/bin/singularity exec centos7c.img date
Sun Jan  8 20:39:08 PST 2017

# explicitly setting TZ to PST still produce wrong result:
sn@backbay:/opt/singularity_repo$ export TZ=PST; /opt/tmp/bin/singularity exec centos7c.img date
Sun Jan  8 20:39:24 PST 2017

# setting TZ to Los Angeles works:
sn@backbay:/opt/singularity_repo$ export TZ=America/Los_Angeles; /opt/tmp/bin/singularity exec centos7c.img date
Sun Jan  8 12:39:39 PST 2017


# EST works, so how come PST doesn't? :
sn@backbay:/opt/singularity_repo$ export TZ=EST; /opt/tmp/bin/singularity exec centos7c.img date
Sun Jan  8 15:40:12 EST 2017
sn@backbay:/opt/singularity_repo$ export TZ=America/New_York; /opt/tmp/bin/singularity exec centos7c.img date
Sun Jan  8 15:40:22 EST 2017


# PST8PDT work as well.  
sn@backbay:/opt/singularity_repo$ export TZ=PST8PDT; /opt/tmp/bin/singularity exec centos7c.img date
Sun Jan  8 12:41:04 PST 2017
sn@backbay:/opt/singularity_repo$ 


NOTE: Singularity is a container env for HPC.  More info at:
http://singularity.lbl.gov/ 
Have build both RHEL and CentOS container image, they indeed have the same problem as expected.
Don't worry too much about the container stuff.  The point is, the default timezone data for a RHEL 6/7 machines, when in PST, yields unexpected result.  Either fix PST to produce correct result, or at the very least have system use "America/Los_Angeles" or other correct TZ string so that correct time will be returned.

The problem is not restricted to just the date command.  ls -l on files will similarly produce wrong time stamp when the host is in PST.  





Expected results:

Expect correct time from "date" and "ls -l" output.


Additional info:

Comment 2 Patsy Griffin 2017-01-09 19:51:48 UTC

Hi,

Thanks for reporting this!  I hope the following input helps explain what you're seeing.

There is a difference between the zone abbreviation (PST) and the actual
time zone name expected by the TZ environment variable.
The time zone names are listed in the /usr/share/zoneinfo directory.

PST and PDT are the abbreviations for the time zone named PST8PDT or America/Los_Angeles.

PST is not a predefined time zone name. 

However, POSIX allows you to create/describe a time zone using a defined syntax and an offset from UTC.

In your examples, it appears that you are actually defining a new time zone named PST with an offset of 0 from UTC.

[pfrankli@pfrankli tzdata]$ TZ=UTC date
Mon Jan  9 19:32:52 UTC 2017
[pfrankli@pfrankli tzdata]$ TZ=ABC date
Mon Jan  9 19:32:58 ABC 2017
[pfrankli@pfrankli tzdata]$ TZ=ABC+1 date
Mon Jan  9 18:33:04 ABC 2017
[pfrankli@pfrankli tzdata]$ TZ=PST date
Mon Jan  9 19:33:12 PST 2017
[pfrankli@pfrankli tzdata]$ TZ=PST+1 date
Mon Jan  9 18:33:16 PST 2017

EST is a valid zone name found in /usr/share/zoneinfo and therefore is expected to work correctly
as you observed in Method B from your examples. 

I'd suggest setting TZ= to either PST8PDT or America/Los_Angeles.

Please let me know if you are still seeing any unexpected behavior.

Thanks!
Patsy

Comment 4 tin.ho 2017-01-09 22:46:58 UTC

Thanks for looking into this.

In /usr/share/zoneinfo/, there are definitions for EST and MST.  But not for PST or CST, even though these designations are reported by the date command.
I am wondering if these zones were dropped by accident, and thus should be added back?

With Method A, I was not trying to define a new time zone.  I was just trying to have the date command show me what time it is if I were in a different timezone.  It worked when TZ was set to EST, but failed for PST.  Precisely because the PST zoneinfo file is no longer present.  Why was this dropped?


More importantly, I think RHEL uses "PST" somewhere internally where it store what timezone should be defaulted to when commands need to show time, such as from ls -l.  I am not sure where this is stored, but I get a feeling such store is doing "PST" and not "PST8PDT" either.  The manifestation of this was shown in Method C when the container can't correctly parse the time between the host and inside the container.   I would imagine similar problem would happen to a docker container too, if such container wasn't created with UTC but time reflecting America/Los_Angeles.

Thanks!

Comment 5 Patsy Griffin 2017-01-09 23:37:30 UTC

(In reply to tin.ho from comment #4)
Hi,

I can understand why you would expect a PST time zone given EST.  I don't know the history of that decision.  At this point, I suspect that adding it would break user described PST zones.

> Thanks for looking into this.
> 
> In /usr/share/zoneinfo/, there are definitions for EST and MST.  But not for
> PST or CST, even though these designations are reported by the date command.
> I am wondering if these zones were dropped by accident, and thus should be
> added back?

I've reviewed as far back as 2013 and there was no record of a PST zoneinfo file under /usr/share/zoneinfo. PST is an abbreviation for the PST8PDT time zone not a time zone name.

> 
> With Method A, I was not trying to define a new time zone.  I was just
> trying to have the date command show me what time it is if I were in a
> different timezone.  It worked when TZ was set to EST, but failed for PST. 
> Precisely because the PST zoneinfo file is no longer present.  Why was this
> dropped?

The TZ environment variable either expects a user described time zone or one of the time zone names listed in /usr/share/zoneinfo.  Since PST is not in the list of zone names under /usr/share/zoneinfo, it was interpreted as a user described zone name.  I understand that this was not your intention but it is the way TZ environment variables are interpreted.

> 
> 
> More importantly, I think RHEL uses "PST" somewhere internally where it
> store what timezone should be defaulted to when commands need to show time,
> such as from ls -l.  I am not sure where this is stored, but I get a feeling
> such store is doing "PST" and not "PST8PDT" either.  The manifestation of
> this was shown in Method C when the container can't correctly parse the time
> between the host and inside the container.   I would imagine similar problem
> would happen to a docker container too, if such container wasn't created
> with UTC but time reflecting America/Los_Angeles.
> 
> Thanks!

Since PST is not defined in /usr/share/zoneinfo, your use of this command resulted in a user described time zone called PST with an offset of 0 from UTC:
export TZ=PST

Please try using one of the time zones listed in /usr/share/zoneinfo and let me know what the results are so that we can figure out what is happening in the container.

Thanks,
Patsy

Comment 7 tin.ho 2017-01-10 21:05:33 UTC

Thanks Patsy for the explanation.

Here is the problem.  The singularity container init script execute date +%Z to determine timezone info.  
In my RHEL6 machine, this return "PST".
I believe the info comes from the equivalent of querying:
tail -1 /etc/localtime
PST8PDT,M3.2.0,M11.1.0


There is a /etc/sysconfig/clock file as well, but my guess is date isn't querying this file.

cat /etc/sysconfig/clock
# This section of this file was automatically generated by cmd. Do not edit manually!
# BEGIN AUTOGENERATED SECTION -- DO NOT REMOVE
ZONE="US/Pacific"
UTC=false
ARC=false
# END AUTOGENERATED SECTION   -- DO NOT REMOVE


Overall, my point is, for any TZ that can be returned from `date +%Z`, such timezone should be defined in /usr/share/zoneinfo and shipped with the OS.

As is, PST is returned by date, but not fully usable due to lack of zoneinfo.  This affect container environment (affect docker as well), and likely other things that one have not fully explored.

If not adding PST into zoneinfo, then date +%Z should return PST8PDT or other string that exactly match what's in zoneinfo.
EST works.  So it should for other timezone.

Regards,
Tin

Comment 10 Patsy Griffin 2017-01-23 21:20:22 UTC

Hi,

It looks like we can also use timedatectl as another way to derive the time zone name:
$ timedatectl status | grep zone | sed -e 's/^[ ]*Time zone: \(.*\) (.*)$/\1/g'
America/New_York
Warning: The system is configured to read the RTC time in the local time zone.
         with time zone changes and daylight saving time adjustments. The RTC

Please let me know if this will work for your case.

Thanks,
Patsy

Comment 11 tin.ho 2017-01-31 18:22:52 UTC

Hi, 

Thanks for looking into this.
I found that export TZ=$(tail -1 /etc/localtime) will set TZ as desired, resulting in expected behavior for date and things like ls -l.

It would still be nice if date +%Z to return something that can be used with TZ consistently.  If not +%Z then perhaps a new "symbol" so it doesn't break existing config.  But honestly, I think if anyone has customized PST (and CST, AKST) would be setting them to Pacific, Central and Alaska.  Thus, a correct fix in date and/or the zoneinfo files would be doing the right thing.

Comment 12 Carlos O'Donell 2017-07-20 07:30:14 UTC

Given that +%Z is not guaranteed to return something usable in TZ, I'm marking this bug CLOSED/NOTABUG. You need to user other mechanism, like timedatectl, to get a timezone value you can use to configure systems similarly.