Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #228827 > unrolled thread

780 files in /usr/share/zoneinfo/

Back to article view | Back to linux.debian.user

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  780 files in /usr/share/zoneinfo/ mike.junk.46@att.net - 2020-11-21 03:50 +0100
    Re: 780 files in /usr/share/zoneinfo/ Andy Smith <andy@strugglers.net> - 2020-11-21 04:10 +0100
    Re: 780 files in /usr/share/zoneinfo/ John Hasler <jhasler@newsguy.com> - 2020-11-21 04:20 +0100
      Re: 780 files in /usr/share/zoneinfo/ Paul Johnson <baloo@ursamundi.org> - 2020-11-21 04:30 +0100
    Re: 780 files in /usr/share/zoneinfo/ <tomas@tuxteam.de> - 2020-11-21 10:00 +0100
      Re: 780 files in /usr/share/zoneinfo/ "Martin McCormick" <martin.m@suddenlink.net> - 2020-11-21 20:30 +0100
        Re: 780 files in /usr/share/zoneinfo/ Andy Smith <andy@strugglers.net> - 2020-11-21 22:40 +0100
          Re: 780 files in /usr/share/zoneinfo/ Stefan Monnier <monnier@iro.umontreal.ca> - 2020-11-21 22:50 +0100
          Re: 780 files in /usr/share/zoneinfo/ "Martin McCormick" <martin.m@suddenlink.net> - 2020-11-22 03:50 +0100
            Re: 780 files in /usr/share/zoneinfo/ Andy Smith <andy@strugglers.net> - 2020-11-22 05:30 +0100
              rsync link corruption with -H and --link-dest "Gareth Evans" <donotspam@fastmail.fm> - 2020-11-22 05:50 +0100
              Re: 780 files in /usr/share/zoneinfo/ "Martin McCormick" <martin.m@suddenlink.net> - 2020-11-30 13:20 +0100
        Re: 780 files in /usr/share/zoneinfo/ Charles Curley <charlescurley@charlescurley.com> - 2020-11-21 23:10 +0100
        Re: Re: 780 files in /usr/share/zoneinfo/ Greg Wooledge <wooledg@eeg.ccf.org> - 2020-11-23 14:00 +0100
          Re: 780 files in /usr/share/zoneinfo/ Charles Curley <charlescurley@charlescurley.com> - 2020-11-23 16:50 +0100
          Re: Re: 780 files in /usr/share/zoneinfo/ Mike McClain <mike.junk.46@att.net> - 2020-11-24 06:50 +0100
            Re: 780 files in /usr/share/zoneinfo/ Greg Wooledge <wooledg@eeg.ccf.org> - 2020-11-24 14:10 +0100
              Re: 780 files in /usr/share/zoneinfo/ rhkramer@gmail.com - 2020-11-24 17:20 +0100
                Re: 780 files in /usr/share/zoneinfo/ John Hasler <jhasler@newsguy.com> - 2020-11-24 17:30 +0100
                  Re: 780 files in /usr/share/zoneinfo/ Curt <curty@free.fr> - 2020-11-24 18:10 +0100
                    Re: 780 files in /usr/share/zoneinfo/ Greg Wooledge <wooledg@eeg.ccf.org> - 2020-11-24 19:10 +0100
                      Re: 780 files in /usr/share/zoneinfo/ rhkramer@gmail.com - 2020-11-24 19:40 +0100
                      Re: 780 files in /usr/share/zoneinfo/ David Wright <deblis@lionunicorn.co.uk> - 2020-11-24 20:50 +0100
                      Re: 780 files in /usr/share/zoneinfo/ Michael Stone <mstone@debian.org> - 2020-11-25 03:00 +0100
            Re: 780 files in /usr/share/zoneinfo/ Stefan Monnier <monnier@iro.umontreal.ca> - 2020-11-24 15:50 +0100
            Re: Re: 780 files in /usr/share/zoneinfo/ Michael Stone <mstone@debian.org> - 2020-11-24 17:10 +0100
              Re: 780 files in /usr/share/zoneinfo/ "Martin McCormick" <martin.m@suddenlink.net> - 2020-11-30 14:10 +0100
            Re: 780 files in /usr/share/zoneinfo/ John Hasler <jhasler@newsguy.com> - 2020-11-24 17:20 +0100
              Re: 780 files in /usr/share/zoneinfo/ Gene Heskett <gheskett@shentel.net> - 2020-11-24 18:20 +0100
            Re: 780 files in /usr/share/zoneinfo/ David Wright <deblis@lionunicorn.co.uk> - 2020-11-24 20:50 +0100
    Re: 780 files in /usr/share/zoneinfo/ David Wright <deblis@lionunicorn.co.uk> - 2020-11-22 00:00 +0100

Page 2 of 2 — ← Prev page 1 [2]

#229021

On Tue, Nov 24, 2020 at 04:45:53PM +0000, Curt wrote:
> I have a problem:
> 
> curty@einstein:~$ TZ=EST date
> Tue Nov 24 11:43:42 EST 2020
> curty@einstein:~$ TZ=PST date
> Tue Nov 24 16:43:54 PST 2020

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".

unicorn:~$ date -u ; TZ=UTC0 date ; TZ=Imaginary/Neverland date
Tue Nov 24 17:54:28 UTC 2020
Tue Nov 24 17:54:28 UTC 2020
Tue Nov 24 17:54:28 Imaginary 2020

TZ=PST is yet another unknown TZ string, so it's treated as "UTC0", or
the Coordinated Universal Time zone, and you don't even get a WARNING
that this is the case.  It just silently gives you a wrong answer.

I've been personally bitten by this, and it sucks.  So much.

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.  You have to discover these
values yourself, using out-of-band means.

One of the ways to generate a valid TZ name, if your target happens to
be in the United States, is to construct one of the old school Unix time
zone names:

EST5EDT
CST6CDT
MST7MDT
PST8PDT

If you can remember "Eastern Central Mountain Pacific", and if you can
remember the numeric offset for any single one of them, then you can
derive the full set.

Another set of TZ labels that works for the USA is the transitional
set that was popular 10-20 years ago:

US/Eastern
US/Central
US/Mountain
US/Pacific

Those are even easier to derive than the "EST5EDT" style ones, albeit
slightly more characters to type.

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.

[toc] | [prev] | [next] | [standalone]

#229026

On Tuesday, November 24, 2020 01:07:10 PM 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".

...

> 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.

Just google [time in <name of place>] (e.g., time in China).  No need to find a 
TZ string.

[toc] | [prev] | [next] | [standalone]

#229030

On Tue 24 Nov 2020 at 13:07:10 (-0500), Greg Wooledge wrote:
> On Tue, Nov 24, 2020 at 04:45:53PM +0000, Curt wrote:
> > I have a problem:
> > 
> > curty@einstein:~$ TZ=EST date
> > Tue Nov 24 11:43:42 EST 2020
> > curty@einstein:~$ TZ=PST date
> > Tue Nov 24 16:43:54 PST 2020
> 
> 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".
> 
> unicorn:~$ date -u ; TZ=UTC0 date ; TZ=Imaginary/Neverland date
> Tue Nov 24 17:54:28 UTC 2020
> Tue Nov 24 17:54:28 UTC 2020
> Tue Nov 24 17:54:28 Imaginary 2020
> 
> TZ=PST is yet another unknown TZ string, so it's treated as "UTC0", or
> the Coordinated Universal Time zone, and you don't even get a WARNING
> that this is the case.  It just silently gives you a wrong answer.
> 
> I've been personally bitten by this, and it sucks.  So much.
> 
> 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.  You have to discover these
> values yourself, using out-of-band means.
> 
> One of the ways to generate a valid TZ name, if your target happens to
> be in the United States, is to construct one of the old school Unix time
> zone names:
> 
> EST5EDT
> CST6CDT
> MST7MDT
> PST8PDT
> 
> If you can remember "Eastern Central Mountain Pacific", and if you can
> remember the numeric offset for any single one of them, then you can
> derive the full set.
> 
> Another set of TZ labels that works for the USA is the transitional
> set that was popular 10-20 years ago:
> 
> US/Eastern
> US/Central
> US/Mountain
> US/Pacific
> 
> Those are even easier to derive than the "EST5EDT" style ones, albeit
> slightly more characters to type.
> 
> 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.

I wrote this a while back; it probably needs another bout of tidying up.

$ type whattime 
whattime is a function
whattime () 
{ 
    [ -z "$1" ] && printf '%s\n' "Usage:        ${FUNCNAME[0]} there [where]
        prints the time in where or where/there or there/where.
        Note that the result has to be Region/Place with a /." 1>&2 && return 1;
    local Wherea="${1,,}" Whereb="${1,,}";
    [ -n "$2" ] && Wherea="${1,,}/${2,,}" && Whereb="${2,,}/${1,,}";
    local Unique1="$(mktemp "${Uniquetrash:-/tmp}/${FUNCNAME[0]}"-"$(date +%s)"-XXXX)";
    local Unique2="$(mktemp "${Uniquetrash:-/tmp}/${FUNCNAME[0]}"-"$(date +%s)"-XXXX)";
    ( cd /usr/share/zoneinfo || return 9;
    ls -1 */* >> "$Unique1";
    grep -i -e "${Wherea// /_}" "$Unique1" >> "$Unique2";
    grep -i -e "${Whereb// /_}" "$Unique1" >> "$Unique2";
    local Nmatches="$(grep -e '/' "$Unique2" | LC_ALL=C sort -u | tee "$Unique1" | wc -l)";
    [ "$Nmatches" = "1" ] && TZ=$(cat "$Unique1") && printf '%s ' "$TZ" && date '+%Y-%m-%d %T %z %A' )
}
$ whattime pari
Europe/Paris 2020-11-24 20:38:35 +0100 Tuesday
$ 

It should work on any single partial match, as demonstrated.
Of course, it helps to know the names of a few major cities.

Cheers,
David.

[toc] | [prev] | [next] | [standalone]

#229049

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.

[toc] | [prev] | [next] | [standalone]

#229006

>     I guess I'm just a little old fashioned. My first computer had
> no storage and my first hard drive was 20M so having a directory
> taking up 3.5MB when all I'm using there is less than 10KB just
> doesn't sit well with me.

I can related to that.

Note that you can also remove all of that directory and use a TZ setting
using the old convention like 'EST5EDT,M3.2.0,M11.1.0'.

Also tar+lzip of that directory reduces it for me from 5.1MB to ~143kB.
`libc` doesn't know how to use it once compressed this way, but you could
manually extract the few files you need from it if/when you need them.


        Stefan

[toc] | [prev] | [next] | [standalone]

#229011

On Mon, Nov 23, 2020 at 10:16:47PM -0600, Mike McClain wrote:
>    I guess I'm just a little old fashioned. My first computer had
>no storage and my first hard drive was 20M so having a directory
>taking up 3.5MB when all I'm using there is less than 10KB just
>doesn't sit well with me.

The kernel, compressed, is larger than that. The initrd needed to boot 
the kernel is also typically larger than that. A modern system has more 
CPU cache than that. At some point trying to save bytes is a waste of 
developer and administrator effort, and 3.5MB in 2020 is well past that 
point. If you want a minimal system, debian isn't for you. Instead, 
you'll need to hand craft every file to make sure it isn't "wasting 
space". If that's your thing, great. But it's just not a focus for 
debian.

[toc] | [prev] | [next] | [standalone]

#229175

Michael Stone <mstone@debian.org> writes:
> The kernel, compressed, is larger than that. The initrd needed to boot the
> kernel is also typically larger than that. A modern system has more CPU
> cache than that. At some point trying to save bytes is a waste of 
> developer
> and administrator effort, and 3.5MB in 2020 is well past that point. If 
> you
> want a minimal system, debian isn't for you. Instead, you'll need to hand
> craft every file to make sure it isn't "wasting space". If that's your
> thing, great. But it's just not a focus for debian.

	About the only place one still needs to think this way is
with embedded systems where the computer is there to manage a
machine of some kind, anything from a lathe to a food processor
to a cement mixer, whatever .  

	General-purpose computers are optimized to have as many
resources as one can cram in to a higher and higher-density box
so a few MB here or there aren't noticed but embedded systems are
optimized with different priorities and one may discover that
this box may be lightning fast but a bit skimpy on data storage.

	I am thinking of things such as cable TV boxes and
dedicated audio-visual appliances that use DSP to emulate complex
and expensive hardware by using mathematical algorithms that
cause the system to decode digital TV signals or route internet
traffic rapidly.

	If you aren't in to trying to modify some sort of
embedded system to do something it wasn't originally designed to
do then ram and storage are getting cheaper by the day and some
things just aren't worth worrying about.

Martin McCormick

[toc] | [prev] | [next] | [standalone]

#229012

Mike McClain writes:
> I guess I'm just a little old fashioned. My first computer had
> no storage

Likewise.

> ...and my first hard drive was 20M...

Likewise.

> ...so having a directory taking up 3.5MB when all I'm using there is
> less than 10KB just doesn't sit well with me.

I have 278GB of unused disk space on this machine.  3.5MB "wasted" does
not bother me at all.  Back when I was coding in hex for the RCA 1802
and using audio cassettes for storage I worried about single bytes.
Times have changed.
-- 
John Hasler 
jhasler@newsguy.com
Elmwood, WI USA

[toc] | [prev] | [next] | [standalone]

#229018

On Tuesday 24 November 2020 11:18:00 John Hasler wrote:

> Mike McClain writes:
> > I guess I'm just a little old fashioned. My first computer had
> > no storage
>
> Likewise.
>
> > ...and my first hard drive was 20M...
>
> Likewise.
>
> > ...so having a directory taking up 3.5MB when all I'm using there is
> > less than 10KB just doesn't sit well with me.
>
> I have 278GB of unused disk space on this machine.  3.5MB "wasted"
> does not bother me at all.  Back when I was coding in hex for the RCA
> 1802 and using audio cassettes for storage I worried about single
> bytes. Times have changed.

Now that brings back very OLD memories from about 1979 John, when I wrote 
a commercial tv production aid to run on a CosMac Super Elf. That tv 
station was still using it several times a day 15 years later, and I 
have a broadcast cart with several copies of it, and a paper copy bagged 
up for posterity on a library shelf above me. First useful program I 
ever wrote and I still have fond memories for the weird architecture, 
and that architectures capabilities, of the 1802. Every byte counted, 
and dead stable despite using quite a bit of self-modifying code.

But you are right, times have changed. Now I'm 86 yo, and am writing 
gcode to carve metal parts I need to make things. 5 linux machines 
running full time here, this one has 32gigs of dram, not the 4k of 
static ram I built from a $400 kit way back then, on an S-100 board.
Keeps me out of the bars don'tcha know.

Thanks for the memory tickle, John.

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page <http://geneslinuxbox.net:6309/gene>

[toc] | [prev] | [next] | [standalone]

#229032

On Mon 23 Nov 2020 at 22:16:47 (-0600), Mike McClain wrote:
> On Mon, Nov 23, 2020 at 07:51:09AM -0500, Greg Wooledge wrote:
> > On Sat, Nov 21, 2020 at 01:20:39PM -0600, Martin McCormick wrote:
> > > 	I just cd'd to that directory and it looks like there's
> > > about 1 GB there.
> >
> > unicorn:~$ du -sh /usr/share/zoneinfo
> > 3.5M	/usr/share/zoneinfo
> > unicorn:~$ find /usr/share/zoneinfo -type f | wc -l
> > 780
> >
> > Either something's wrong on your system -- in which case you should try
> > to figure out what it is -- or something's wrong with your interpretation
> > of what you're seeing.
> >
> > (And yes, I know find | wc -l isn't an accurate way to count files if
> > their names are unrestricted.  Here I'm assuming there aren't a huge
> > number of filenames in /usr/share/zoneinfo/ with newlines.)
> 
>     Since I'm the one that started this discussion, I'd like to say
> "Thank You" to all that offered their insight.
>     I guess I'm just a little old fashioned. My first computer had
> no storage and my first hard drive was 20M so having a directory
> taking up 3.5MB when all I'm using there is less than 10KB just
> doesn't sit well with me.

Well, it would be interesting to compare the functionality provided by
that computer with what's under your fingertips now.

After pruning all the stuff that "doubles" disk size, and the
unnecessary anti-virus and backup software etc, the entire
DOS6.22 OS comes in at under 3MB. But there's no comparison.

>     In over 20 years running Linux I've never found a use for that
> extra 3.5MB data and I wonder how many do. I'm curious Greg, how often
> have you used that data?

Well, you seem to use it, judging by your emails when you send them
under this persona. For example, you appear to have observed DST
during the summer, and relocated some aspect of your life in the fall.

>     Locale is another area where there is a lot of data that the
> average user, I suspect, has no use for and localepurge in Debian, at
> least, is hamstrung by the packagers, hooking it to dpkg and
> disableing it for any other use. Running localepurge on the CL is a
> noop but doesn't tell you so, look at the code.

I'm not sure how you calculate an average locale from the variety
of users worldwide. A mode might be possible.

>     Sorry I didn't mean to rant.
> Thanks again for the input.

Pleasure. For the quiet life, I'd recommend to let sleeping dogs lie.

Cheers,
David.

[toc] | [prev] | [next] | [standalone]

#228879

On Sat 21 Nov 2020 at 02:30:08 (+0000), mike.junk.46@att.net wrote:
> Of the 780 files in /usr/share/zoneinfo/ America/Chicago and CST6CDT are the only two that might apply to me. Are the rest of any use to me at all? If so how? And, yes, I understand that they need to be supplied for every zone in the world initially but am curious if there is any use for them after one's own time zone is set.

Compared with the language files discussed around
https://lists.debian.org/debian-user/2020/10/msg00290.html
I would say this is small fry:

$ find /usr/share/zoneinfo/ -type f -exec cat {} + | wc -c
1192831
$ 

(I imagine most of the disk usage is directories, links,
and dead space at the end of all those little files.)

Ironically, you seem to have lost your email's time zone,
assuming you're still on this continent.

Cheers,
David.

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | linux.debian.user

csiph-web