Re: 780 files in /usr/share/zoneinfo/

[Andrei POPESCU]

On Ma, 01 dec 20, 08:11:01, Robert Tonkavich wrote:
> I am very sorry for my Input.

What is there to be sorry about?

Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser


signature.asc
Description: PGP signature

Re: 780 files in /usr/share/zoneinfo/

[Robert Tonkavich]

I am very sorry for my Input.


On Tue, Dec 1, 2020 at 12:28 AM David Wright 
wrote:

> On Mon 30 Nov 2020 at 18:25:00 (-0600), John Hasler wrote:
> > Stefan writes:
> > > Is there leap-second information in the zoneinfo files?
> >
> > No, but that is where is should be.
>
> It appears to be present, at least in the difference between the
> "posix" and "right" trees; and its history can be demonstrated:
>
> $ for j in $(seq 1971 2020) ; do TZ=UTC touch -t "$j"0401.00 "$j-apr"
> ; done
> $ for j in $(seq 1971 2020) ; do TZ=UTC touch -t "$j"1001.00 "$j-oct"
> ; done
> $ TZ=right/UTC dirr-time-in-full -Gg
> .:
> total 0
> -rw-r- 1 0 1971-04-01 00:00:00.0 + 1971-apr
> -rw-r- 1 0 1971-10-01 00:00:00.0 + 1971-oct
> -rw-r- 1 0 1972-04-01 00:00:00.0 + 1972-apr
> -rw-r- 1 0 1972-09-30 23:59:59.0 + 1972-oct
> -rw-r- 1 0 1973-03-31 23:59:58.0 + 1973-apr
> -rw-r- 1 0 1973-09-30 23:59:58.0 + 1973-oct
> -rw-r- 1 0 1974-03-31 23:59:57.0 + 1974-apr
> -rw-r- 1 0 1974-09-30 23:59:57.0 + 1974-oct
> -rw-r- 1 0 1975-03-31 23:59:56.0 + 1975-apr
> -rw-r- 1 0 1975-09-30 23:59:56.0 + 1975-oct
> -rw-r- 1 0 1976-03-31 23:59:55.0 + 1976-apr
> -rw-r- 1 0 1976-09-30 23:59:55.0 + 1976-oct
> -rw-r- 1 0 1977-03-31 23:59:54.0 + 1977-apr
> -rw-r- 1 0 1977-09-30 23:59:54.0 + 1977-oct
> -rw-r- 1 0 1978-03-31 23:59:53.0 + 1978-apr
> -rw-r- 1 0 1978-09-30 23:59:53.0 + 1978-oct
> -rw-r- 1 0 1979-03-31 23:59:52.0 + 1979-apr
> -rw-r- 1 0 1979-09-30 23:59:52.0 + 1979-oct
> -rw-r- 1 0 1980-03-31 23:59:51.0 + 1980-apr
> -rw-r- 1 0 1980-09-30 23:59:51.0 + 1980-oct
> -rw-r- 1 0 1981-03-31 23:59:51.0 + 1981-apr
> -rw-r- 1 0 1981-09-30 23:59:50.0 + 1981-oct
> -rw-r- 1 0 1982-03-31 23:59:50.0 + 1982-apr
> -rw-r- 1 0 1982-09-30 23:59:49.0 + 1982-oct
> -rw-r- 1 0 1983-03-31 23:59:49.0 + 1983-apr
> -rw-r- 1 0 1983-09-30 23:59:48.0 + 1983-oct
> -rw-r- 1 0 1984-03-31 23:59:48.0 + 1984-apr
> -rw-r- 1 0 1984-09-30 23:59:48.0 + 1984-oct
> -rw-r- 1 0 1985-03-31 23:59:48.0 + 1985-apr
> -rw-r- 1 0 1985-09-30 23:59:47.0 + 1985-oct
> -rw-r- 1 0 1986-03-31 23:59:47.0 + 1986-apr
> -rw-r- 1 0 1986-09-30 23:59:47.0 + 1986-oct
> -rw-r- 1 0 1987-03-31 23:59:47.0 + 1987-apr
> -rw-r- 1 0 1987-09-30 23:59:47.0 + 1987-oct
> -rw-r- 1 0 1988-03-31 23:59:46.0 + 1988-apr
> -rw-r- 1 0 1988-09-30 23:59:46.0 + 1988-oct
> -rw-r- 1 0 1989-03-31 23:59:46.0 + 1989-apr
> -rw-r- 1 0 1989-09-30 23:59:46.0 + 1989-oct
> -rw-r- 1 0 1990-03-31 23:59:45.0 + 1990-apr
> -rw-r- 1 0 1990-09-30 23:59:45.0 + 1990-oct
> -rw-r- 1 0 1991-03-31 23:59:44.0 + 1991-apr
> -rw-r- 1 0 1991-09-30 23:59:44.0 + 1991-oct
> -rw-r- 1 0 1992-03-31 23:59:44.0 + 1992-apr
> -rw-r- 1 0 1992-09-30 23:59:43.0 + 1992-oct
> -rw-r- 1 0 1993-03-31 23:59:43.0 + 1993-apr
> -rw-r- 1 0 1993-09-30 23:59:42.0 + 1993-oct
> -rw-r- 1 0 1994-03-31 23:59:42.0 + 1994-apr
> -rw-r- 1 0 1994-09-30 23:59:41.0 + 1994-oct
> -rw-r- 1 0 1995-03-31 23:59:41.0 + 1995-apr
> -rw-r- 1 0 1995-09-30 23:59:41.0 + 1995-oct
> -rw-r- 1 0 1996-03-31 23:59:40.0 + 1996-apr
> -rw-r- 1 0 1996-09-30 23:59:40.0 + 1996-oct
> -rw-r- 1 0 1997-03-31 23:59:40.0 + 1997-apr
> -rw-r- 1 0 1997-09-30 23:59:39.0 + 1997-oct
> -rw-r- 1 0 1998-03-31 23:59:39.0 + 1998-apr
> -rw-r- 1 0 1998-09-30 23:59:39.0 + 1998-oct
> -rw-r- 1 0 1999-03-31 23:59:38.0 + 1999-apr
> -rw-r- 1 0 1999-09-30 23:59:38.0 + 1999-oct
> -rw-r- 1 0 2000-03-31 23:59:38.0 + 2000-apr
> -rw-r- 1 0 2000-09-30 23:59:38.0 + 2000-oct
> -rw-r- 1 0 2001-03-31 23:59:38.0 + 2001-apr
> -rw-r- 1 0 2001-09-30 23:59:38.0 + 2001-oct
> -rw-r- 1 0 2002-03-31 23:59:38.0 + 2002-apr
> -rw-r- 1 0 2002-09-30 23:59:38.0 + 2002-oct
> -rw-r- 1 0 2003-03-31 23:59:38.0 + 2003-apr
> -rw-r- 1 0 2003-09-30 23:59:38.0 + 2003-oct
> -rw-r- 1 0 2004-03-31 23:59:38.0 + 2004-apr
> -rw-r- 1 0 2004-09-30 23:59:38.0 + 2004-oct
> -rw-r- 1 0 2005-03-31 23:59:38.0 + 2005-apr
> -rw-r- 1 0 2005-09-30 23:59:38.0 + 2005-oct
> -rw-r- 1 0 

Re: 780 files in /usr/share/zoneinfo/

[David Wright]

On Mon 30 Nov 2020 at 18:25:00 (-0600), John Hasler wrote:
> Stefan writes:
> > Is there leap-second information in the zoneinfo files?
> 
> No, but that is where is should be.

It appears to be present, at least in the difference between the
"posix" and "right" trees; and its history can be demonstrated:

$ for j in $(seq 1971 2020) ; do TZ=UTC touch -t "$j"0401.00 "$j-apr" ; done
$ for j in $(seq 1971 2020) ; do TZ=UTC touch -t "$j"1001.00 "$j-oct" ; done
$ TZ=right/UTC dirr-time-in-full -Gg
.:
total 0
-rw-r- 1 0 1971-04-01 00:00:00.0 + 1971-apr
-rw-r- 1 0 1971-10-01 00:00:00.0 + 1971-oct
-rw-r- 1 0 1972-04-01 00:00:00.0 + 1972-apr
-rw-r- 1 0 1972-09-30 23:59:59.0 + 1972-oct
-rw-r- 1 0 1973-03-31 23:59:58.0 + 1973-apr
-rw-r- 1 0 1973-09-30 23:59:58.0 + 1973-oct
-rw-r- 1 0 1974-03-31 23:59:57.0 + 1974-apr
-rw-r- 1 0 1974-09-30 23:59:57.0 + 1974-oct
-rw-r- 1 0 1975-03-31 23:59:56.0 + 1975-apr
-rw-r- 1 0 1975-09-30 23:59:56.0 + 1975-oct
-rw-r- 1 0 1976-03-31 23:59:55.0 + 1976-apr
-rw-r- 1 0 1976-09-30 23:59:55.0 + 1976-oct
-rw-r- 1 0 1977-03-31 23:59:54.0 + 1977-apr
-rw-r- 1 0 1977-09-30 23:59:54.0 + 1977-oct
-rw-r- 1 0 1978-03-31 23:59:53.0 + 1978-apr
-rw-r- 1 0 1978-09-30 23:59:53.0 + 1978-oct
-rw-r- 1 0 1979-03-31 23:59:52.0 + 1979-apr
-rw-r- 1 0 1979-09-30 23:59:52.0 + 1979-oct
-rw-r- 1 0 1980-03-31 23:59:51.0 + 1980-apr
-rw-r- 1 0 1980-09-30 23:59:51.0 + 1980-oct
-rw-r- 1 0 1981-03-31 23:59:51.0 + 1981-apr
-rw-r- 1 0 1981-09-30 23:59:50.0 + 1981-oct
-rw-r- 1 0 1982-03-31 23:59:50.0 + 1982-apr
-rw-r- 1 0 1982-09-30 23:59:49.0 + 1982-oct
-rw-r- 1 0 1983-03-31 23:59:49.0 + 1983-apr
-rw-r- 1 0 1983-09-30 23:59:48.0 + 1983-oct
-rw-r- 1 0 1984-03-31 23:59:48.0 + 1984-apr
-rw-r- 1 0 1984-09-30 23:59:48.0 + 1984-oct
-rw-r- 1 0 1985-03-31 23:59:48.0 + 1985-apr
-rw-r- 1 0 1985-09-30 23:59:47.0 + 1985-oct
-rw-r- 1 0 1986-03-31 23:59:47.0 + 1986-apr
-rw-r- 1 0 1986-09-30 23:59:47.0 + 1986-oct
-rw-r- 1 0 1987-03-31 23:59:47.0 + 1987-apr
-rw-r- 1 0 1987-09-30 23:59:47.0 + 1987-oct
-rw-r- 1 0 1988-03-31 23:59:46.0 + 1988-apr
-rw-r- 1 0 1988-09-30 23:59:46.0 + 1988-oct
-rw-r- 1 0 1989-03-31 23:59:46.0 + 1989-apr
-rw-r- 1 0 1989-09-30 23:59:46.0 + 1989-oct
-rw-r- 1 0 1990-03-31 23:59:45.0 + 1990-apr
-rw-r- 1 0 1990-09-30 23:59:45.0 + 1990-oct
-rw-r- 1 0 1991-03-31 23:59:44.0 + 1991-apr
-rw-r- 1 0 1991-09-30 23:59:44.0 + 1991-oct
-rw-r- 1 0 1992-03-31 23:59:44.0 + 1992-apr
-rw-r- 1 0 1992-09-30 23:59:43.0 + 1992-oct
-rw-r- 1 0 1993-03-31 23:59:43.0 + 1993-apr
-rw-r- 1 0 1993-09-30 23:59:42.0 + 1993-oct
-rw-r- 1 0 1994-03-31 23:59:42.0 + 1994-apr
-rw-r- 1 0 1994-09-30 23:59:41.0 + 1994-oct
-rw-r- 1 0 1995-03-31 23:59:41.0 + 1995-apr
-rw-r- 1 0 1995-09-30 23:59:41.0 + 1995-oct
-rw-r- 1 0 1996-03-31 23:59:40.0 + 1996-apr
-rw-r- 1 0 1996-09-30 23:59:40.0 + 1996-oct
-rw-r- 1 0 1997-03-31 23:59:40.0 + 1997-apr
-rw-r- 1 0 1997-09-30 23:59:39.0 + 1997-oct
-rw-r- 1 0 1998-03-31 23:59:39.0 + 1998-apr
-rw-r- 1 0 1998-09-30 23:59:39.0 + 1998-oct
-rw-r- 1 0 1999-03-31 23:59:38.0 + 1999-apr
-rw-r- 1 0 1999-09-30 23:59:38.0 + 1999-oct
-rw-r- 1 0 2000-03-31 23:59:38.0 + 2000-apr
-rw-r- 1 0 2000-09-30 23:59:38.0 + 2000-oct
-rw-r- 1 0 2001-03-31 23:59:38.0 + 2001-apr
-rw-r- 1 0 2001-09-30 23:59:38.0 + 2001-oct
-rw-r- 1 0 2002-03-31 23:59:38.0 + 2002-apr
-rw-r- 1 0 2002-09-30 23:59:38.0 + 2002-oct
-rw-r- 1 0 2003-03-31 23:59:38.0 + 2003-apr
-rw-r- 1 0 2003-09-30 23:59:38.0 + 2003-oct
-rw-r- 1 0 2004-03-31 23:59:38.0 + 2004-apr
-rw-r- 1 0 2004-09-30 23:59:38.0 + 2004-oct
-rw-r- 1 0 2005-03-31 23:59:38.0 + 2005-apr
-rw-r- 1 0 2005-09-30 23:59:38.0 + 2005-oct
-rw-r- 1 0 2006-03-31 23:59:37.0 + 2006-apr
-rw-r- 1 0 2006-09-30 23:59:37.0 + 2006-oct
-rw-r- 1 0 2007-03-31 23:59:37.0 + 2007-apr
-rw-r- 1 0 2007-09-30 23:59:37.0 + 2007-oct
-rw-r- 1 0 2008-03-31 

Re: 780 files in /usr/share/zoneinfo/

[David Wright]

On Mon 30 Nov 2020 at 17:28:50 (-0500), Stefan Monnier wrote:
> > Finally, competing with the politicians, the scientists have
> > complicated things with their atomic time and leap seconds.
> 
> Is there leap-second information in the zoneinfo files?
> Isn't this info "global" (i.e. not specific to particular time zones)?
> 
> 
> Stefan "who for some reason presumed it's kept elsewhere but
> couldn't say why"

AIUI:

$ TZ=posix/America/Chicago date; TZ=right/America/Chicago date
Mon Nov 30 18:45:34 CST 2020
Mon Nov 30 18:45:07 CST 2020
$ 

I don't know whether their history is encoded somewhere. I only
recall the first leap second because IIRC the BBC changed the
pips about the same time (making the sixth pip longer).

Cheers,
David.

Re: 780 files in /usr/share/zoneinfo/

[John Hasler]

Stefan writes:
> Is there leap-second information in the zoneinfo files?

No, but that is where is should be.

> Isn't this info "global" (i.e. not specific to particular time zones)?

It is specific to a particular *time*.  
-- 
John Hasler 
jhas...@newsguy.com
Elmwood, WI USA

Re: 780 files in /usr/share/zoneinfo/

[Stefan Monnier]

> Finally, competing with the politicians, the scientists have
> complicated things with their atomic time and leap seconds.

Is there leap-second information in the zoneinfo files?
Isn't this info "global" (i.e. not specific to particular time zones)?


Stefan "who for some reason presumed it's kept elsewhere but
couldn't say why"

Re: 780 files in /usr/share/zoneinfo/

[David Wright]

On Mon 30 Nov 2020 at 13:13:27 (-0500), Robert Tonkavich wrote:
> 
> There are only 24 Time Zones that Encompass the Earth. Is 780 files
> overboard?
> 
> I think Yes.

You might like to read this take on the complexity of time zones as
actually observed. As you can read there, even countries and states
are not sufficient to express the granularity, so many of the links
provided into the dataset are at the level of cities, islands, etc.

https://qz.com/357697/time-zone-deviants-part-i-the-strangest-time-zones-in-the-world/

You can also observe how far most people live from there own solar
time by googling   solar time vs local time   and selecting "images".

Another complication that you seem unaware of is that the dataset
also expresses the history of timezone regions, and you can observe
some of the workload in refining this data by perusing the
/usr/share/doc/tzdata/changelog.gz file.

You need this historical information to be able to correctly interpret
any records kept in local time. This fragment shows how local time
lurched around in early wartime Britain:

$ zdump -V -c 1939,1943 GB
GB  Sun Apr 16 01:59:59 1939 UT = Sun Apr 16 01:59:59 1939 GMT isdst=0 gmtoff=0
GB  Sun Apr 16 02:00:00 1939 UT = Sun Apr 16 03:00:00 1939 BST isdst=1 
gmtoff=3600
GB  Sun Nov 19 01:59:59 1939 UT = Sun Nov 19 02:59:59 1939 BST isdst=1 
gmtoff=3600
GB  Sun Nov 19 02:00:00 1939 UT = Sun Nov 19 02:00:00 1939 GMT isdst=0 gmtoff=0
GB  Sun Feb 25 01:59:59 1940 UT = Sun Feb 25 01:59:59 1940 GMT isdst=0 gmtoff=0
GB  Sun Feb 25 02:00:00 1940 UT = Sun Feb 25 03:00:00 1940 BST isdst=1 
gmtoff=3600
GB  Sun May  4 00:59:59 1941 UT = Sun May  4 01:59:59 1941 BST isdst=1 
gmtoff=3600
GB  Sun May  4 01:00:00 1941 UT = Sun May  4 03:00:00 1941 BDST isdst=1 
gmtoff=7200
GB  Sun Aug 10 00:59:59 1941 UT = Sun Aug 10 02:59:59 1941 BDST isdst=1 
gmtoff=7200
GB  Sun Aug 10 01:00:00 1941 UT = Sun Aug 10 02:00:00 1941 BST isdst=1 
gmtoff=3600
GB  Sun Apr  5 00:59:59 1942 UT = Sun Apr  5 01:59:59 1942 BST isdst=1 
gmtoff=3600
GB  Sun Apr  5 01:00:00 1942 UT = Sun Apr  5 03:00:00 1942 BDST isdst=1 
gmtoff=7200
GB  Sun Aug  9 00:59:59 1942 UT = Sun Aug  9 02:59:59 1942 BDST isdst=1 
gmtoff=7200
GB  Sun Aug  9 01:00:00 1942 UT = Sun Aug  9 02:00:00 1942 BST isdst=1 
gmtoff=3600
$ 

Finally, competing with the politicians, the scientists have
complicated things with their atomic time and leap seconds.

> On Mon, Nov 30, 2020 at 1:00 PM Charlie Gibbs  wrote:
> > On Mon, 30 Nov 2020 14:10:02 +0100 "Martin McCormick" wrote:
> >
> >  > 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.
> >
> > To a great extent that's true, although there is the danger
> > of falling into the attitude that abundance justifies waste.
> > (This can once again make things worth worrying about,
> > well before it might be necessary if you do things efficiently.)
> >
> > However, there's another consideration: the KISS principle.
> > A system that needs 780 files is going to be a lot more complex
> > and difficult to understand than one that gets by with one or two.
> > This can have serious impacts on reliability and maintainability.
> >
> > I'm seeing more and more cases of systems falling apart because
> > they're becoming too complex to administer.  Some of this is because
> > they "just grew", without proper planning and pruning.  Some of it
> > is due to that effect described by Blaise Pascal, who once apologized
> > for the length of the letter he was writing because he didn't have
> > time to make it shorter.  And some, I'm sad to say, are a deliberate
> > effort at obfuscation: an old trick long used by politicians to keep
> > the electorate blissfully ignorant of their shenanigans, and now
> > adopted by some equally nefarious system designers.

Cheers,
David.

Re: 780 files in /usr/share/zoneinfo/

[deloptes]

Greg Wooledge wrote:

> This is completely inaccurate.  Time zones were not devised by drawing
> equally-spaced meridian lines along the globe.  They were invented
> by political entities.  They aren't static, either -- they change
> from time to time, as political regimes change.
> 
> Time zones are not tied to the geography of the earth, nor even to
> political boundaries.  There are places that have two competing time
> zones, one time zone for some of the people living there, and another
> for the rest of the people living there.
> 
> Time zones aren't guaranteed to deviate from UTC by an integral number
> of hours.  There are some that are off by a fraction of an hour.
> 
> There are time zones pairings that differ from each other part of the
> year, and concide with each other the rest of the year.
> 
> Try to think of the strangest, most obtuse, most ridiculous rules you
> can -- real time zones are WORSE than that.

It is a total mess - if it wasn't those files, it were be chaos.

In fact I admire people 3000y ago could manage time better than we do.

Re: 780 files in /usr/share/zoneinfo/

[John Hasler]

Robert Tonkavich writes:
> There are only 24 Time Zones that Encompass the Earth.

It's far more complicated than that.  There are 24 geographic time zones
but zoneinfo has to deal with local civil time as regulated, often
rather capriciously, by national, regional, and local governments.
Examples: Do you know how many versions of DST/Summer Time there are?
Did you know that some jurisdictions set their clocks 1/2 hour away from
what their geographic time zone indicates?  That many jurisdictions
ignore their geographic time zone and use a politically convenient one?
That some countries have "moved" across the international date line?
-- 
John Hasler 
jhas...@newsguy.com
Elmwood, WI USA

Re: 780 files in /usr/share/zoneinfo/

[Michael Stone]

On Mon, Nov 30, 2020 at 09:44:13AM -0800, Charlie Gibbs wrote:

However, there's another consideration: the KISS principle.
A system that needs 780 files is going to be a lot more complex
and difficult to understand than one that gets by with one or two.


Actually, it's a lot more straightforward and reliant on simple 
principles than one big file with hundreds of special cases. 

Re: 780 files in /usr/share/zoneinfo/

[Greg Wooledge]

On Mon, Nov 30, 2020 at 01:13:27PM -0500, Robert Tonkavich wrote:
> There are only 24 Time Zones that Encompass the Earth. Is 780 files
> overboard?
> 
> I think Yes.

This is completely inaccurate.  Time zones were not devised by drawing
equally-spaced meridian lines along the globe.  They were invented
by political entities.  They aren't static, either -- they change
from time to time, as political regimes change.

Time zones are not tied to the geography of the earth, nor even to
political boundaries.  There are places that have two competing time
zones, one time zone for some of the people living there, and another
for the rest of the people living there.

Time zones aren't guaranteed to deviate from UTC by an integral number
of hours.  There are some that are off by a fraction of an hour.

There are time zones pairings that differ from each other part of the
year, and concide with each other the rest of the year.

Try to think of the strangest, most obtuse, most ridiculous rules you
can -- real time zones are WORSE than that.

Re: 780 files in /usr/share/zoneinfo/

[Robert Tonkavich]

All,

There are only 24 Time Zones that Encompass the Earth. Is 780 files
overboard?

I think Yes.

Robert Tonkavich

On Mon, Nov 30, 2020 at 1:00 PM Charlie Gibbs  wrote:

> On Mon, 30 Nov 2020 14:10:02 +0100 "Martin McCormick"
>  wrote:
>
>  > 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.
>
> To a great extent that's true, although there is the danger
> of falling into the attitude that abundance justifies waste.
> (This can once again make things worth worrying about,
> well before it might be necessary if you do things efficiently.)
>
> However, there's another consideration: the KISS principle.
> A system that needs 780 files is going to be a lot more complex
> and difficult to understand than one that gets by with one or two.
> This can have serious impacts on reliability and maintainability.
>
> I'm seeing more and more cases of systems falling apart because
> they're becoming too complex to administer.  Some of this is because
> they "just grew", without proper planning and pruning.  Some of it
> is due to that effect described by Blaise Pascal, who once apologized
> for the length of the letter he was writing because he didn't have
> time to make it shorter.  And some, I'm sad to say, are a deliberate
> effort at obfuscation: an old trick long used by politicians to keep
> the electorate blissfully ignorant of their shenanigans, and now
> adopted by some equally nefarious system designers.
>
> --
> /~\  Charlie Gibbs  |  Microsoft is a dictatorship.
> \ /|  Apple is a cult.
>   X   I'm really at ac.dekanfrus |  Linux is anarchy.
> / \  if you read it the right way.  |  Pick your poison.
>
>

-- 
Thank You

Robert M Tonkavich
989-205-2683

Re: 780 files in /usr/share/zoneinfo/

[Charlie Gibbs]

On Mon, 30 Nov 2020 14:10:02 +0100 "Martin McCormick" 
 wrote:


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

To a great extent that's true, although there is the danger
of falling into the attitude that abundance justifies waste.
(This can once again make things worth worrying about,
well before it might be necessary if you do things efficiently.)

However, there's another consideration: the KISS principle.
A system that needs 780 files is going to be a lot more complex
and difficult to understand than one that gets by with one or two.
This can have serious impacts on reliability and maintainability.

I'm seeing more and more cases of systems falling apart because
they're becoming too complex to administer.  Some of this is because
they "just grew", without proper planning and pruning.  Some of it
is due to that effect described by Blaise Pascal, who once apologized
for the length of the letter he was writing because he didn't have
time to make it shorter.  And some, I'm sad to say, are a deliberate
effort at obfuscation: an old trick long used by politicians to keep
the electorate blissfully ignorant of their shenanigans, and now
adopted by some equally nefarious system designers.

--
/~\  Charlie Gibbs  |  Microsoft is a dictatorship.
\ /|  Apple is a cult.
 X   I'm really at ac.dekanfrus |  Linux is anarchy.
/ \  if you read it the right way.  |  Pick your poison.

Re: 780 files in /usr/share/zoneinfo/

[Martin McCormick]

Michael Stone  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

Re: 780 files in /usr/share/zoneinfo/

[Martin McCormick]

Andy Smith  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

Re: 780 files in /usr/share/zoneinfo/

[Michael Stone]

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.

Re: 780 files in /usr/share/zoneinfo/

[Mike McClain]

On Tue, Nov 24, 2020 at 02:48:12PM +0100, Kamil Jo?ca wrote:
> Mike McClain  writes:
>
> [...]
> > 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
> I disagree.
> Even quite small enterprises work internationally now.
> And it  is important to me if my coworker from Bangalore has working
> time or is in bed before calling him :)
> So "TZ=Asia/Kolkata date" is your friend :)
>
>
> KJ
> --
> http://stopstopnop.pl/stop_stopnop.pl_o_nas.html

I'm quite sure you're right for businesses.
I wonder if there is any way to tell how many Linux installations are
being used by businesses versus are used by people like me who use it
as a home computer with no business in mind?
Be well,
Mike
--
Telling pious lies to trusting children is a form of abuse,
plain and simple. - Daniel Dennett, 2010-01-12

Re: 780 files in /usr/share/zoneinfo/

[Kamil Jońca]

rhkra...@gmail.com writes:

> 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 ] (e.g., time in China).  No need to find 
> a 
> TZ string.

Heh. OP concers about 3.5 MB of locale tz data and you want to install
browser which is usually much bigger?
KJ

-- 
http://stopstopnop.pl/stop_stopnop.pl_o_nas.html

Re: 780 files in /usr/share/zoneinfo/

[David Wright]

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.

Re: 780 files in /usr/share/zoneinfo/

[David Wright]

On Tue 24 Nov 2020 at 13:07:10 (-0500), Greg Wooledge wrote:
> On Tue, Nov 24, 2020 at 04:45:53PM +, 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)"-)";
local Unique2="$(mktemp "${Uniquetrash:-/tmp}/${FUNCNAME[0]}"-"$(date 
+%s)"-)";
( 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.

Re: 780 files in /usr/share/zoneinfo/

[rhkramer]

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 ] (e.g., time in China).  No need to find a 
TZ string.

Re: 780 files in /usr/share/zoneinfo/

[Kamil Jońca]

Mike McClain  writes:

[...]
> 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
I disagree.
Even quite small enterprises work internationally now.
And it  is important to me if my coworker from Bangalore has working
time or is in bed before calling him :)
So "TZ=Asia/Kolkata date" is your friend :)


KJ
-- 
http://stopstopnop.pl/stop_stopnop.pl_o_nas.html

Re: 780 files in /usr/share/zoneinfo/

[Greg Wooledge]

On Tue, Nov 24, 2020 at 04:45:53PM +, 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.

Re: 780 files in /usr/share/zoneinfo/

[Gene Heskett]

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 

Re: 780 files in /usr/share/zoneinfo/

[Curt]

On 2020-11-24, John Hasler  wrote:
> rhkramer writes:
>> To find out the time in some other time zone, I find it convenient to
>> just google [time in ] (e.g., time in China).
>
> "TZ= 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

Re: 780 files in /usr/share/zoneinfo/

[John Hasler]

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

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

Re: 780 files in /usr/share/zoneinfo/

[John Hasler]

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 
jhas...@newsguy.com
Elmwood, WI USA

Re: 780 files in /usr/share/zoneinfo/

[rhkramer]

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 .

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

Re: Re: 780 files in /usr/share/zoneinfo/

[Michael Stone]

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.

Re: 780 files in /usr/share/zoneinfo/

[Stefan Monnier]

> 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

Re: 780 files in /usr/share/zoneinfo/

[Greg Wooledge]

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 .

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.

Re: Re: 780 files in /usr/share/zoneinfo/

[Mike McClain]

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

Re: 780 files in /usr/share/zoneinfo/

[Charles Curley]

On Mon, 23 Nov 2020 07:51:09 -0500
Greg Wooledge  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/

Re: Re: 780 files in /usr/share/zoneinfo/

[Greg Wooledge]

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

Re: 780 files in /usr/share/zoneinfo/

[Andy Smith]

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

Re: 780 files in /usr/share/zoneinfo/

[Martin McCormick]

Andy Smith  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

Re: 780 files in /usr/share/zoneinfo/

[David Wright]

On Sat 21 Nov 2020 at 02:30:08 (+), mike.junk...@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.

Re: 780 files in /usr/share/zoneinfo/

[Charles Curley]

On Sat, 21 Nov 2020 13:20:39 -0600
"Martin McCormick"  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/

Re: 780 files in /usr/share/zoneinfo/

[Stefan Monnier]

> 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

Re: 780 files in /usr/share/zoneinfo/

[Andy Smith]

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

Re: 780 files in /usr/share/zoneinfo/

[Martin McCormick]

 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

Re: 780 files in /usr/share/zoneinfo/

[tomas]

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


signature.asc
Description: Digital signature

Re: 780 files in /usr/share/zoneinfo/

[Paul Johnson]

On Fri, Nov 20, 2020 at 9:18 PM John Hasler  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...

Re: 780 files in /usr/share/zoneinfo/

[John Hasler]

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 
jhas...@newsguy.com
Elmwood, WI USA

Re: 780 files in /usr/share/zoneinfo/

[Andy Smith]

Hi Mike,

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

780 files in /usr/share/zoneinfo/

[mike . junk . 46]

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