Re: 780 files in /usr/share/zoneinfo/
On Tue, Nov 24, 2020 at 01:07:10PM -0500, Greg Wooledge wrote:
As I said, figuring out the valid TZ strings for a given location on
our planet is a challenge. Unfortunately, the ... fine people ... who
devised the standards for this sort of thing thought it would be really
super clever to treat ALL unknown TZ strings as if they were "UTC0".
It's the result of a layering of standards. The old pre-TZ-file way of
doing things parsed the TZ string to create the rule. You can call your
timezones anything you want (you're making the rule!) and the degenerate
case has a zero offset.
unicorn:~$ TZ=PST date ; TZ=PST8PDT date ; TZ=America/Los_Angeles date
Tue Nov 24 17:56:16 PST 2020
Tue Nov 24 09:56:16 PST 2020
Tue Nov 24 09:56:16 PST 2020
To add insult to injury, the string that date(1) gives you as OUTPUT
(in this case, "PST") is not accepted by the very same program as INPUT.
In fact, I don't know of any way to get date(1) to give an output string
that you can use as a valid TZ input string.
date ; date --iso=seconds ; date --iso=seconds -d `date --iso=seconds`
Tue 24 Nov 2020 08:50:29 PM EST
2020-11-24T20:50:29-05:00
2020-11-24T20:50:29-05:00
Just use numeric timezone offsets for anything being done
programatically. It's not possible to use human-friendly timezone names
for that because they're ambiguous.
And use ISO8601 format for everything. Seriously, everything.
Outside of the USA, you'll probably need to go with the "nearest big
city" names that are the current vogue. The best way to use those is
probably "ls /usr/share/zoneinfo", choose your continent, and then
(for example) "ls /usr/share/zoneinfo/Asia". Then pick a city from
the resulting set, and pray.
If there's a better way, I don't know it.
most people just configuring their time zone using their gui
configuration manager. if you choose not to do it that way then yeah,
you'll have to do some research. also, as suggested upthread, most
people do this at install time and never touch it again.
Reply to: