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 1 of 2  [1] 2  Next page →

#228827 — 780 files in /usr/share/zoneinfo/

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.
Thanks,
Mike

[toc] | [next] | [standalone]

#228828

Hi Mike,

On Sat, Nov 21, 2020 at 02:30:08AM +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.

It's the Olson database, needed for any application that will want
to know the time in another time zone, or parse such.

    https://en.wikipedia.org/wiki/Tz_database

The files are tiny. It's not worth removing them IMHO. It's 3½MiB of
space on my system.

Cheers,
Andy

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

#228829

Mike writes:
> 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?

Do you ever need to convert the time and date in some distant time zone
to your local time or vice versa?  The "date" command can do that for
you using that database.

Also, the database is updated (even in Stable) when jurisdictions make
changes such as moving the start and end dates for daylight savings
time.

It's tiny and useful.  leave it alone.
-- 
John Hasler 
jhasler@newsguy.com
Elmwood, WI USA

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

#228830

[Multipart message — attachments visible in raw view] — view raw

On Fri, Nov 20, 2020 at 9:18 PM John Hasler <jhasler@newsguy.com> wrote:

> Mike writes:
> > 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?
>
> Do you ever need to convert the time and date in some distant time zone
> to your local time or vice versa?  The "date" command can do that for
> you using that database.
>
> Also, the database is updated (even in Stable) when jurisdictions make
> changes such as moving the start and end dates for daylight savings
> time.
>
> It's tiny and useful.  leave it alone.
>

 I concur.  And it's only going to get more useful with each update as the
world's time gets more complicated.  Especially if you happen to be in the
northwestern US, where half of the Boise and Portland metro areas will now
be off the other half by an hour half the year...

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

#228836

[Multipart message — attachments visible in raw view] — view raw

On Sat, Nov 21, 2020 at 02:30:08AM +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 [...]
> [...] if there is any use for them after one's own time zone is set.

Suppose a hacker logs into your computer from far, far away, say
from somewhere in Nepal.

Surely you'd want this person to see the time adapted to their
locale? That's the least courtesy you can be expected to provide?

;-P

Now putting my tongue out of my cheek again: in Unix, a computer
"has" no time zone or language -- people have those. And since,
again in Unix, several people can be logged in [1] at the same time,
it's up to the user's environment [2] to decide on time zone,
language, etc.

This concept is surprising at first coming from other cultures,
where Microsoft was happy to sell you another complete version
of Windows if you wanted your computer to talk to you, e.g.
Portuguese (and yet another for Brazilian Portuguese, greedy as
they are).

Of course, Microsoft has caught up (they are trying since the
mid-90s), but not without some spectacular messups. Remember that
one where (I think it was Windows 95), while trying to automate
the spring DST transition were spotted dithering endlessly between
2AM and 3AM?

Unix has had this abstraction always: there's the internal time,
and there's the time shown to the user, which depends on the user.

There's the error itself, and there's the error message shown to
the user. And so on.

Cheers

[1] This concept extends to other remote communication things,
   like http.
[2] See man 7 locale for the gory details

 - t

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

#228864

<tomas@tuxteam.de> writes:
> Suppose a hacker logs into your computer from far, far away, say
> from somewhere in Nepal.
> 
> Surely you'd want this person to see the time adapted to their
> locale? That's the least courtesy you can be expected to provide?
> 
> ;-P
> 
> Now putting my tongue out of my cheek again: in Unix, a computer
> "has" no time zone or language -- people have those. And since,
> again in Unix, several people can be logged in [1] at the same time,
> it's up to the user's environment [2] to decide on time zone,
> language, etc.
> 
> This concept is surprising at first coming from other cultures,
> where Microsoft was happy to sell you another complete version
> of Windows if you wanted your computer to talk to you, e.g.
> Portuguese (and yet another for Brazilian Portuguese, greedy as
> they are).
> 
> Of course, Microsoft has caught up (they are trying since the
> mid-90s), but not without some spectacular messups. Remember that
> one where (I think it was Windows 95), while trying to automate
> the spring DST transition were spotted dithering endlessly between
> 2AM and 3AM?
> 
> Unix has had this abstraction always: there's the internal time,
> and there's the time shown to the user, which depends on the user.
> 
> There's the error itself, and there's the error message shown to
> the user. And so on.
> 
> Cheers

	I just cd'd to that directory and it looks like there's
about 1 GB there.  I think it is cool to have all that info and I
even configured a linux system for BST so cron would record shows
I was interested in from the BBC.

	It works perfectly when we go from Summer time to
standard time in Winter because North America and the UK don't
switch at the same time but it all works.

	I've wished one could just set certain parts of the
computer to other times but I can also understand why this could
be a problem.

	By the way, I have never been outside the United States
but am an amateur radio operator and learned at a very young age
to appreciate those time zones if one wants to know when to
listen for interesting things.

Martin

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

#228870

Hi Martin,

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.

Are you sure about this? There is no Debian or Ubuntu host I have
access to that has a /usr/share/zoneinfo/ that contains more than
4MiB of data. For yours to have 256 times this much is quite an
aberration. What did you type to determine that your
/usr/share/zoneinfo/ has 1GiB of data in it?

> 	I've wished one could just set certain parts of the
> computer to other times but I can also understand why this could
> be a problem.

You can set any process to have a different time zone by use of
environment variables.

$ date
Sat 21 Nov 21:34:55 UTC 2020
$ TZ=America/Los_Angeles date
Sat 21 Nov 13:35:04 PST 2020

Cheers,
Andy

-- 
https://bitfolk.com/ -- No-nonsense VPS hosting

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

#228875

> Are you sure about this? There is no Debian or Ubuntu host I have
> access to that has a /usr/share/zoneinfo/ that contains more than
> 4MiB of data.

FWIW:

    % du -sh /usr/share/zoneinfo/.
    5.1M    /usr/share/zoneinfo/.
    0%

This is on a "bog standard" Debian i386 testing (with incremental
updates for the last 17 years or so).

> For yours to have 256 times this much is quite an aberration.

Quite definitely.


        Stefan

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

#228897

Andy Smith <andy@strugglers.net> writes:
> Hi Martin,
> 
> Are you sure about this? There is no Debian or Ubuntu host I have
> access to that has a /usr/share/zoneinfo/ that contains more than
> 4MiB of data. For yours to have 256 times this much is quite an
> aberration. What did you type to determine that your
> /usr/share/zoneinfo/ has 1GiB of data in it?

find . -name "*" -exec ls -l {} \;  \
|grep -F / \
| awk ' { total += $5 } END { print total }'

	That usually just adds the sizes of all the files it can
find all the way through the tree.

	If this is not an accurate way to determine how many
bytes there are in a directory then that would be the reason for
the discrepancy.

> 
> >       I've wished one could just set certain parts of the
> > computer to other times but I can also understand why this could
> > be a problem.
> 
> You can set any process to have a different time zone by use of
> environment variables.
> 
> $ date
> Sat 21 Nov 21:34:55 UTC 2020
> $ TZ=America/Los_Angeles date
> Sat 21 Nov 13:35:04 PST 2020

	That is very true but cron only works in the time zone
for wherever the TZ for the system is set.

	On the system I have set to British time, my local login
shell has TZ=America/Chicago so I read Central Standard Time for
file time stamps but if I set a cron job, it runs on either
British Summer Time or British standard time which is the same as
UTC during Winter.


> Cheers,
> Andy

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

#228902

Hi Martin,

On Sat, Nov 21, 2020 at 08:48:51PM -0600, Martin McCormick wrote:
> find . -name "*" -exec ls -l {} \;  \
> |grep -F / \
> | awk ' { total += $5 } END { print total }'
> 
> 	That usually just adds the sizes of all the files it can
> find all the way through the tree.
> 
> 	If this is not an accurate way to determine how many
> bytes there are in a directory then that would be the reason for
> the discrepancy.

The same file can be reached by multiple names. So by doing this you
end up, in this case, with a ~256x amplification.

A simple "du -sh" does a better job here!

> cron only works in the time zone for wherever the TZ for the
> system is set.

Ah, I see. I've never tried it but I believe that systemd timers can
have a time spec that includes time zone, so you can set timers that
fire on a different time zone to that used by the rest of the system.

$ systemd-analyze calendar '11:00 Europe/London'
  Original form: 11:00 Europe/London
Normalized form: *-*-* 11:00:00 Europe/London
    Next elapse: Sun 2020-11-22 11:00:00 UTC
       From now: 6h left

Cheers,
Andy

-- 
https://bitfolk.com/ -- No-nonsense VPS hosting

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

#228903 — rsync link corruption with -H and --link-dest

Hi all,

I have asked this question on both the rsync mailing list and serverfault.com but got no response from either.

I would be grateful, if this isn't too off-topic, if anyone could explain the following:

man rsync for -H includes:

"If you specify a --link-dest directory that contains hard links, the linking of the destination files against the --link-dest files can cause some paths in the destination to become linked together due to the --link-dest associations."

How and/or why does this happen?  What sort of scenario might lead to it?

Thanks
Gareth

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

#229174

Andy Smith <andy@strugglers.net> writes:
> Hi Martin,
> 
> On Sat, Nov 21, 2020 at 08:48:51PM -0600, Martin McCormick wrote:
> > find . -name "*" -exec ls -l {} \;  \
> > |grep -F / \
> > | awk ' { total += $5 } END { print total }'
> >
> >       That usually just adds the sizes of all the files it can
> > find all the way through the tree.
> >
> >       If this is not an accurate way to determine how many
> > bytes there are in a directory then that would be the reason for
> > the discrepancy.
> 
> The same file can be reached by multiple names. So by doing this you
> end up, in this case, with a ~256x amplification.
> 
> A simple "du -sh" does a better job here!
> 
> > cron only works in the time zone for wherever the TZ for the
> > system is set.
> 
> Ah, I see. I've never tried it but I believe that systemd timers can
> have a time spec that includes time zone, so you can set timers that
> fire on a different time zone to that used by the rest of the system.
> 
> $ systemd-analyze calendar '11:00 Europe/London'
>   Original form: 11:00 Europe/London
> Normalized form: *-*-* 11:00:00 Europe/London
>     Next elapse: Sun 2020-11-22 11:00:00 UTC
>        From now: 6h left
> 
> Cheers,

I do appreciate being corrected, here.  What we really want to
know, here, is how much precious disk space is occupied by
whatever data base we are interested in.  Links make copies of
files appear to exist when the data were only written once even

Martin

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

#228876

On Sat, 21 Nov 2020 13:20:39 -0600
"Martin McCormick" <martin.m@suddenlink.net> wrote:

> I just cd'd to that directory and it looks like there's
> about 1 GB there.

Show us what you did. As in, copy and paste from a terminal. E.g.:

root@hawk:/usr/share/zoneinfo# du -hs
3.5M	.
root@hawk:/usr/share/zoneinfo# uname -r
4.19.0-6-amd64
root@hawk:/usr/share/zoneinfo# pre tzdata
tzdata	2020d-0+deb10u1		all
root@hawk:/usr/share/zoneinfo# 


-- 
Does anybody read signatures any more?

https://charlescurley.com
https://charlescurley.com/blog/

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

#228953

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

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

#228963

On Mon, 23 Nov 2020 07:51:09 -0500
Greg Wooledge <wooledg@eeg.ccf.org> wrote:

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

You are also assuming that there are no hard links. In this case, the
assumption is correct.

root@jhegaala:~# find /usr/share/zoneinfo -type f | xargs ls -i | cut -f1 -d' ' | sort -n | wc -l
780
root@jhegaala:~# 


-- 
Does anybody read signatures any more?

https://charlescurley.com
https://charlescurley.com/blog/

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

#228986

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.
    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?
    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.
    Sorry I didn't mean to rant.
Thanks again for the input.
Be well,
Mike
--
"At birth, men are by nature of good heart."
    - _Young_Fu_    Elizabeth F. Lewis

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

#229002

On Mon, Nov 23, 2020 at 10:16:47PM -0600, Mike McClain wrote:
>     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?

A few times a year, at most.  For others, it will depend on how often
you travel to other time zones, or interact with people in other time
zones, or would simply like to know what time it is in <place>.

unicorn:~$ date ; TZ=Asia/Hong_Kong date
Tue Nov 24 08:07:53 EST 2020
Tue Nov 24 21:07:53 HKT 2020

Then again, just figuring out the *name* of the target time zone is a
challenge in and of itself.

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

#229014

On Tuesday, November 24, 2020 08:09:16 AM Greg Wooledge wrote:
> A few times a year, at most.  For others, it will depend on how often
> you travel to other time zones, or interact with people in other time
> zones, or would simply like to know what time it is in <place>.

To find out the time in some other time zone, I find it convenient to just 
google [time in <name of place>] (e.g., time in China).

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

#229015

rhkramer writes:
> To find out the time in some other time zone, I find it convenient to
> just google [time in <name of place>] (e.g., time in China).

"TZ=<time zone> date" is quicker.  "date -d 'time and date in other timezone'"
converts a given time and date to local time and date. 
-- 
John Hasler 
jhasler@newsguy.com
Elmwood, WI USA

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

#229017

On 2020-11-24, John Hasler <jhasler@newsguy.com> wrote:
> rhkramer writes:
>> To find out the time in some other time zone, I find it convenient to
>> just google [time in <name of place>] (e.g., time in China).
>
> "TZ=<time zone> date" is quicker.  "date -d 'time and date in other timezone'"
> converts a given time and date to local time and date. 

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

However,

curty@einstein:~$ TZ=":America/Los_Angeles" date
Tue Nov 24 08:40:42 PST 2020

And yet,

curty@einstein:~$ TZ=":America/San_Francisco" date
Tue Nov 24 16:42:03 America 2020

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

Page 1 of 2  [1] 2  Next page →

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

csiph-web