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

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!

(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

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

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

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.

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.