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


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

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

Started byCharlie Gibbs <cgibbs@surfnaked.ca>
First post2020-11-30 19:10 +0100
Last post2020-11-30 19:30 +0100
Articles 13 — 9 participants

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


Contents

  Re: 780 files in /usr/share/zoneinfo/ Charlie Gibbs <cgibbs@surfnaked.ca> - 2020-11-30 19:10 +0100
    Re: 780 files in /usr/share/zoneinfo/ Robert Tonkavich <rmtonkavich@gmail.com> - 2020-11-30 19:20 +0100
      Re: 780 files in /usr/share/zoneinfo/ Greg Wooledge <wooledg@eeg.ccf.org> - 2020-11-30 19:30 +0100
        Re: 780 files in /usr/share/zoneinfo/ deloptes <deloptes@gmail.com> - 2020-11-30 20:10 +0100
      Re: 780 files in /usr/share/zoneinfo/ John Hasler <jhasler@newsguy.com> - 2020-11-30 20:00 +0100
      Re: 780 files in /usr/share/zoneinfo/ David Wright <deblis@lionunicorn.co.uk> - 2020-11-30 22:00 +0100
        Re: 780 files in /usr/share/zoneinfo/ Stefan Monnier <monnier@iro.umontreal.ca> - 2020-11-30 23:30 +0100
          Re: 780 files in /usr/share/zoneinfo/ John Hasler <jhasler@newsguy.com> - 2020-12-01 01:30 +0100
            Re: 780 files in /usr/share/zoneinfo/ David Wright <deblis@lionunicorn.co.uk> - 2020-12-01 06:30 +0100
              Re: 780 files in /usr/share/zoneinfo/ Robert Tonkavich <rmtonkavich@gmail.com> - 2020-12-01 14:20 +0100
                Re: 780 files in /usr/share/zoneinfo/ Andrei POPESCU <andreimpopescu@gmail.com> - 2020-12-02 11:10 +0100
          Re: 780 files in /usr/share/zoneinfo/ David Wright <deblis@lionunicorn.co.uk> - 2020-12-01 01:50 +0100
    Re: 780 files in /usr/share/zoneinfo/ Michael Stone <mstone@debian.org> - 2020-11-30 19:30 +0100

#229178 — Re: 780 files in /usr/share/zoneinfo/

FromCharlie Gibbs <cgibbs@surfnaked.ca>
Date2020-11-30 19:10 +0100
SubjectRe: 780 files in /usr/share/zoneinfo/
Message-ID<BgVMB-3hx-11@gated-at.bofh.it>
On Mon, 30 Nov 2020 14:10:02 +0100 "Martin McCormick" 
<martin.m@suddenlink.net> 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.
\ /  <cgibbs@kltpzyxm.invalid>      |  Apple is a cult.
  X   I'm really at ac.dekanfrus     |  Linux is anarchy.
/ \  if you read it the right way.  |  Pick your poison.

[toc] | [next] | [standalone]


#229179

FromRobert Tonkavich <rmtonkavich@gmail.com>
Date2020-11-30 19:20 +0100
Message-ID<BgVWh-3kM-9@gated-at.bofh.it>
In reply to#229178

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

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 <cgibbs@surfnaked.ca> wrote:

> On Mon, 30 Nov 2020 14:10:02 +0100 "Martin McCormick"
> <martin.m@suddenlink.net> 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.
> \ /  <cgibbs@kltpzyxm.invalid>      |  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

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


#229180

FromGreg Wooledge <wooledg@eeg.ccf.org>
Date2020-11-30 19:30 +0100
Message-ID<BgW5X-3nZ-1@gated-at.bofh.it>
In reply to#229179
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.

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


#229183

Fromdeloptes <deloptes@gmail.com>
Date2020-11-30 20:10 +0100
Message-ID<BgWIG-3QC-9@gated-at.bofh.it>
In reply to#229180
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.

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


#229182

FromJohn Hasler <jhasler@newsguy.com>
Date2020-11-30 20:00 +0100
Message-ID<BgWz0-3xM-13@gated-at.bofh.it>
In reply to#229179
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 
jhasler@newsguy.com
Elmwood, WI USA

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


#229184

FromDavid Wright <deblis@lionunicorn.co.uk>
Date2020-11-30 22:00 +0100
Message-ID<BgYr9-4Gi-21@gated-at.bofh.it>
In reply to#229179
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 <cgibbs@surfnaked.ca> 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.

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


#229185

FromStefan Monnier <monnier@iro.umontreal.ca>
Date2020-11-30 23:30 +0100
Message-ID<BgZQd-5Eh-1@gated-at.bofh.it>
In reply to#229184
> 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"

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


#229186

FromJohn Hasler <jhasler@newsguy.com>
Date2020-12-01 01:30 +0100
Message-ID<Bh1Il-6Mf-5@gated-at.bofh.it>
In reply to#229185
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 
jhasler@newsguy.com
Elmwood, WI USA

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


#229189

FromDavid Wright <deblis@lionunicorn.co.uk>
Date2020-12-01 06:30 +0100
Message-ID<Bh6oF-1Dy-5@gated-at.bofh.it>
In reply to#229186
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"04010000.00 "$j-apr" ; done
$ for j in $(seq 1971 2020) ; do TZ=UTC touch -t "$j"10010000.00 "$j-oct" ; done
$ TZ=right/UTC dirr-time-in-full -Gg
.:
total 0
-rw-r----- 1 0 1971-04-01 00:00:00.000000000 +0000 1971-apr
-rw-r----- 1 0 1971-10-01 00:00:00.000000000 +0000 1971-oct
-rw-r----- 1 0 1972-04-01 00:00:00.000000000 +0000 1972-apr
-rw-r----- 1 0 1972-09-30 23:59:59.000000000 +0000 1972-oct
-rw-r----- 1 0 1973-03-31 23:59:58.000000000 +0000 1973-apr
-rw-r----- 1 0 1973-09-30 23:59:58.000000000 +0000 1973-oct
-rw-r----- 1 0 1974-03-31 23:59:57.000000000 +0000 1974-apr
-rw-r----- 1 0 1974-09-30 23:59:57.000000000 +0000 1974-oct
-rw-r----- 1 0 1975-03-31 23:59:56.000000000 +0000 1975-apr
-rw-r----- 1 0 1975-09-30 23:59:56.000000000 +0000 1975-oct
-rw-r----- 1 0 1976-03-31 23:59:55.000000000 +0000 1976-apr
-rw-r----- 1 0 1976-09-30 23:59:55.000000000 +0000 1976-oct
-rw-r----- 1 0 1977-03-31 23:59:54.000000000 +0000 1977-apr
-rw-r----- 1 0 1977-09-30 23:59:54.000000000 +0000 1977-oct
-rw-r----- 1 0 1978-03-31 23:59:53.000000000 +0000 1978-apr
-rw-r----- 1 0 1978-09-30 23:59:53.000000000 +0000 1978-oct
-rw-r----- 1 0 1979-03-31 23:59:52.000000000 +0000 1979-apr
-rw-r----- 1 0 1979-09-30 23:59:52.000000000 +0000 1979-oct
-rw-r----- 1 0 1980-03-31 23:59:51.000000000 +0000 1980-apr
-rw-r----- 1 0 1980-09-30 23:59:51.000000000 +0000 1980-oct
-rw-r----- 1 0 1981-03-31 23:59:51.000000000 +0000 1981-apr
-rw-r----- 1 0 1981-09-30 23:59:50.000000000 +0000 1981-oct
-rw-r----- 1 0 1982-03-31 23:59:50.000000000 +0000 1982-apr
-rw-r----- 1 0 1982-09-30 23:59:49.000000000 +0000 1982-oct
-rw-r----- 1 0 1983-03-31 23:59:49.000000000 +0000 1983-apr
-rw-r----- 1 0 1983-09-30 23:59:48.000000000 +0000 1983-oct
-rw-r----- 1 0 1984-03-31 23:59:48.000000000 +0000 1984-apr
-rw-r----- 1 0 1984-09-30 23:59:48.000000000 +0000 1984-oct
-rw-r----- 1 0 1985-03-31 23:59:48.000000000 +0000 1985-apr
-rw-r----- 1 0 1985-09-30 23:59:47.000000000 +0000 1985-oct
-rw-r----- 1 0 1986-03-31 23:59:47.000000000 +0000 1986-apr
-rw-r----- 1 0 1986-09-30 23:59:47.000000000 +0000 1986-oct
-rw-r----- 1 0 1987-03-31 23:59:47.000000000 +0000 1987-apr
-rw-r----- 1 0 1987-09-30 23:59:47.000000000 +0000 1987-oct
-rw-r----- 1 0 1988-03-31 23:59:46.000000000 +0000 1988-apr
-rw-r----- 1 0 1988-09-30 23:59:46.000000000 +0000 1988-oct
-rw-r----- 1 0 1989-03-31 23:59:46.000000000 +0000 1989-apr
-rw-r----- 1 0 1989-09-30 23:59:46.000000000 +0000 1989-oct
-rw-r----- 1 0 1990-03-31 23:59:45.000000000 +0000 1990-apr
-rw-r----- 1 0 1990-09-30 23:59:45.000000000 +0000 1990-oct
-rw-r----- 1 0 1991-03-31 23:59:44.000000000 +0000 1991-apr
-rw-r----- 1 0 1991-09-30 23:59:44.000000000 +0000 1991-oct
-rw-r----- 1 0 1992-03-31 23:59:44.000000000 +0000 1992-apr
-rw-r----- 1 0 1992-09-30 23:59:43.000000000 +0000 1992-oct
-rw-r----- 1 0 1993-03-31 23:59:43.000000000 +0000 1993-apr
-rw-r----- 1 0 1993-09-30 23:59:42.000000000 +0000 1993-oct
-rw-r----- 1 0 1994-03-31 23:59:42.000000000 +0000 1994-apr
-rw-r----- 1 0 1994-09-30 23:59:41.000000000 +0000 1994-oct
-rw-r----- 1 0 1995-03-31 23:59:41.000000000 +0000 1995-apr
-rw-r----- 1 0 1995-09-30 23:59:41.000000000 +0000 1995-oct
-rw-r----- 1 0 1996-03-31 23:59:40.000000000 +0000 1996-apr
-rw-r----- 1 0 1996-09-30 23:59:40.000000000 +0000 1996-oct
-rw-r----- 1 0 1997-03-31 23:59:40.000000000 +0000 1997-apr
-rw-r----- 1 0 1997-09-30 23:59:39.000000000 +0000 1997-oct
-rw-r----- 1 0 1998-03-31 23:59:39.000000000 +0000 1998-apr
-rw-r----- 1 0 1998-09-30 23:59:39.000000000 +0000 1998-oct
-rw-r----- 1 0 1999-03-31 23:59:38.000000000 +0000 1999-apr
-rw-r----- 1 0 1999-09-30 23:59:38.000000000 +0000 1999-oct
-rw-r----- 1 0 2000-03-31 23:59:38.000000000 +0000 2000-apr
-rw-r----- 1 0 2000-09-30 23:59:38.000000000 +0000 2000-oct
-rw-r----- 1 0 2001-03-31 23:59:38.000000000 +0000 2001-apr
-rw-r----- 1 0 2001-09-30 23:59:38.000000000 +0000 2001-oct
-rw-r----- 1 0 2002-03-31 23:59:38.000000000 +0000 2002-apr
-rw-r----- 1 0 2002-09-30 23:59:38.000000000 +0000 2002-oct
-rw-r----- 1 0 2003-03-31 23:59:38.000000000 +0000 2003-apr
-rw-r----- 1 0 2003-09-30 23:59:38.000000000 +0000 2003-oct
-rw-r----- 1 0 2004-03-31 23:59:38.000000000 +0000 2004-apr
-rw-r----- 1 0 2004-09-30 23:59:38.000000000 +0000 2004-oct
-rw-r----- 1 0 2005-03-31 23:59:38.000000000 +0000 2005-apr
-rw-r----- 1 0 2005-09-30 23:59:38.000000000 +0000 2005-oct
-rw-r----- 1 0 2006-03-31 23:59:37.000000000 +0000 2006-apr
-rw-r----- 1 0 2006-09-30 23:59:37.000000000 +0000 2006-oct
-rw-r----- 1 0 2007-03-31 23:59:37.000000000 +0000 2007-apr
-rw-r----- 1 0 2007-09-30 23:59:37.000000000 +0000 2007-oct
-rw-r----- 1 0 2008-03-31 23:59:37.000000000 +0000 2008-apr
-rw-r----- 1 0 2008-09-30 23:59:37.000000000 +0000 2008-oct
-rw-r----- 1 0 2009-03-31 23:59:36.000000000 +0000 2009-apr
-rw-r----- 1 0 2009-09-30 23:59:36.000000000 +0000 2009-oct
-rw-r----- 1 0 2010-03-31 23:59:36.000000000 +0000 2010-apr
-rw-r----- 1 0 2010-09-30 23:59:36.000000000 +0000 2010-oct
-rw-r----- 1 0 2011-03-31 23:59:36.000000000 +0000 2011-apr
-rw-r----- 1 0 2011-09-30 23:59:36.000000000 +0000 2011-oct
-rw-r----- 1 0 2012-03-31 23:59:36.000000000 +0000 2012-apr
-rw-r----- 1 0 2012-09-30 23:59:35.000000000 +0000 2012-oct
-rw-r----- 1 0 2013-03-31 23:59:35.000000000 +0000 2013-apr
-rw-r----- 1 0 2013-09-30 23:59:35.000000000 +0000 2013-oct
-rw-r----- 1 0 2014-03-31 23:59:35.000000000 +0000 2014-apr
-rw-r----- 1 0 2014-09-30 23:59:35.000000000 +0000 2014-oct
-rw-r----- 1 0 2015-03-31 23:59:35.000000000 +0000 2015-apr
-rw-r----- 1 0 2015-09-30 23:59:34.000000000 +0000 2015-oct
-rw-r----- 1 0 2016-03-31 23:59:34.000000000 +0000 2016-apr
-rw-r----- 1 0 2016-09-30 23:59:34.000000000 +0000 2016-oct
-rw-r----- 1 0 2017-03-31 23:59:33.000000000 +0000 2017-apr
-rw-r----- 1 0 2017-09-30 23:59:33.000000000 +0000 2017-oct
-rw-r----- 1 0 2018-03-31 23:59:33.000000000 +0000 2018-apr
-rw-r----- 1 0 2018-09-30 23:59:33.000000000 +0000 2018-oct
-rw-r----- 1 0 2019-03-31 23:59:33.000000000 +0000 2019-apr
-rw-r----- 1 0 2019-09-30 23:59:33.000000000 +0000 2019-oct
-rw-r----- 1 0 2020-03-31 23:59:33.000000000 +0000 2020-apr
-rw-r----- 1 0 2020-09-30 23:59:33.000000000 +0000 2020-oct
$ 

Each leap second occurs halfway between a pair of lines above
(the March and September options have never been used), and
all have been positive.

Bear in mind that UTC and Atomic Time had already parted company
by 10 seconds before the start of leap seconds, so we're running
37 seconds slow, rather than the 27 shown above.

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

Yes, 23:59:60 is inserted into UTC, so it will have occurred at
around dinner-time in the US (for those who eat "lunch" around noon).

Cheers,
David.

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


#229195

FromRobert Tonkavich <rmtonkavich@gmail.com>
Date2020-12-01 14:20 +0100
Message-ID<BhdJw-65v-1@gated-at.bofh.it>
In reply to#229189

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

I am very sorry for my Input.


On Tue, Dec 1, 2020 at 12:28 AM David Wright <deblis@lionunicorn.co.uk>
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"04010000.00 "$j-apr"
> ; done
> $ for j in $(seq 1971 2020) ; do TZ=UTC touch -t "$j"10010000.00 "$j-oct"
> ; done
> $ TZ=right/UTC dirr-time-in-full -Gg
> .:
> total 0
> -rw-r----- 1 0 1971-04-01 00:00:00.000000000 +0000 1971-apr
> -rw-r----- 1 0 1971-10-01 00:00:00.000000000 +0000 1971-oct
> -rw-r----- 1 0 1972-04-01 00:00:00.000000000 +0000 1972-apr
> -rw-r----- 1 0 1972-09-30 23:59:59.000000000 +0000 1972-oct
> -rw-r----- 1 0 1973-03-31 23:59:58.000000000 +0000 1973-apr
> -rw-r----- 1 0 1973-09-30 23:59:58.000000000 +0000 1973-oct
> -rw-r----- 1 0 1974-03-31 23:59:57.000000000 +0000 1974-apr
> -rw-r----- 1 0 1974-09-30 23:59:57.000000000 +0000 1974-oct
> -rw-r----- 1 0 1975-03-31 23:59:56.000000000 +0000 1975-apr
> -rw-r----- 1 0 1975-09-30 23:59:56.000000000 +0000 1975-oct
> -rw-r----- 1 0 1976-03-31 23:59:55.000000000 +0000 1976-apr
> -rw-r----- 1 0 1976-09-30 23:59:55.000000000 +0000 1976-oct
> -rw-r----- 1 0 1977-03-31 23:59:54.000000000 +0000 1977-apr
> -rw-r----- 1 0 1977-09-30 23:59:54.000000000 +0000 1977-oct
> -rw-r----- 1 0 1978-03-31 23:59:53.000000000 +0000 1978-apr
> -rw-r----- 1 0 1978-09-30 23:59:53.000000000 +0000 1978-oct
> -rw-r----- 1 0 1979-03-31 23:59:52.000000000 +0000 1979-apr
> -rw-r----- 1 0 1979-09-30 23:59:52.000000000 +0000 1979-oct
> -rw-r----- 1 0 1980-03-31 23:59:51.000000000 +0000 1980-apr
> -rw-r----- 1 0 1980-09-30 23:59:51.000000000 +0000 1980-oct
> -rw-r----- 1 0 1981-03-31 23:59:51.000000000 +0000 1981-apr
> -rw-r----- 1 0 1981-09-30 23:59:50.000000000 +0000 1981-oct
> -rw-r----- 1 0 1982-03-31 23:59:50.000000000 +0000 1982-apr
> -rw-r----- 1 0 1982-09-30 23:59:49.000000000 +0000 1982-oct
> -rw-r----- 1 0 1983-03-31 23:59:49.000000000 +0000 1983-apr
> -rw-r----- 1 0 1983-09-30 23:59:48.000000000 +0000 1983-oct
> -rw-r----- 1 0 1984-03-31 23:59:48.000000000 +0000 1984-apr
> -rw-r----- 1 0 1984-09-30 23:59:48.000000000 +0000 1984-oct
> -rw-r----- 1 0 1985-03-31 23:59:48.000000000 +0000 1985-apr
> -rw-r----- 1 0 1985-09-30 23:59:47.000000000 +0000 1985-oct
> -rw-r----- 1 0 1986-03-31 23:59:47.000000000 +0000 1986-apr
> -rw-r----- 1 0 1986-09-30 23:59:47.000000000 +0000 1986-oct
> -rw-r----- 1 0 1987-03-31 23:59:47.000000000 +0000 1987-apr
> -rw-r----- 1 0 1987-09-30 23:59:47.000000000 +0000 1987-oct
> -rw-r----- 1 0 1988-03-31 23:59:46.000000000 +0000 1988-apr
> -rw-r----- 1 0 1988-09-30 23:59:46.000000000 +0000 1988-oct
> -rw-r----- 1 0 1989-03-31 23:59:46.000000000 +0000 1989-apr
> -rw-r----- 1 0 1989-09-30 23:59:46.000000000 +0000 1989-oct
> -rw-r----- 1 0 1990-03-31 23:59:45.000000000 +0000 1990-apr
> -rw-r----- 1 0 1990-09-30 23:59:45.000000000 +0000 1990-oct
> -rw-r----- 1 0 1991-03-31 23:59:44.000000000 +0000 1991-apr
> -rw-r----- 1 0 1991-09-30 23:59:44.000000000 +0000 1991-oct
> -rw-r----- 1 0 1992-03-31 23:59:44.000000000 +0000 1992-apr
> -rw-r----- 1 0 1992-09-30 23:59:43.000000000 +0000 1992-oct
> -rw-r----- 1 0 1993-03-31 23:59:43.000000000 +0000 1993-apr
> -rw-r----- 1 0 1993-09-30 23:59:42.000000000 +0000 1993-oct
> -rw-r----- 1 0 1994-03-31 23:59:42.000000000 +0000 1994-apr
> -rw-r----- 1 0 1994-09-30 23:59:41.000000000 +0000 1994-oct
> -rw-r----- 1 0 1995-03-31 23:59:41.000000000 +0000 1995-apr
> -rw-r----- 1 0 1995-09-30 23:59:41.000000000 +0000 1995-oct
> -rw-r----- 1 0 1996-03-31 23:59:40.000000000 +0000 1996-apr
> -rw-r----- 1 0 1996-09-30 23:59:40.000000000 +0000 1996-oct
> -rw-r----- 1 0 1997-03-31 23:59:40.000000000 +0000 1997-apr
> -rw-r----- 1 0 1997-09-30 23:59:39.000000000 +0000 1997-oct
> -rw-r----- 1 0 1998-03-31 23:59:39.000000000 +0000 1998-apr
> -rw-r----- 1 0 1998-09-30 23:59:39.000000000 +0000 1998-oct
> -rw-r----- 1 0 1999-03-31 23:59:38.000000000 +0000 1999-apr
> -rw-r----- 1 0 1999-09-30 23:59:38.000000000 +0000 1999-oct
> -rw-r----- 1 0 2000-03-31 23:59:38.000000000 +0000 2000-apr
> -rw-r----- 1 0 2000-09-30 23:59:38.000000000 +0000 2000-oct
> -rw-r----- 1 0 2001-03-31 23:59:38.000000000 +0000 2001-apr
> -rw-r----- 1 0 2001-09-30 23:59:38.000000000 +0000 2001-oct
> -rw-r----- 1 0 2002-03-31 23:59:38.000000000 +0000 2002-apr
> -rw-r----- 1 0 2002-09-30 23:59:38.000000000 +0000 2002-oct
> -rw-r----- 1 0 2003-03-31 23:59:38.000000000 +0000 2003-apr
> -rw-r----- 1 0 2003-09-30 23:59:38.000000000 +0000 2003-oct
> -rw-r----- 1 0 2004-03-31 23:59:38.000000000 +0000 2004-apr
> -rw-r----- 1 0 2004-09-30 23:59:38.000000000 +0000 2004-oct
> -rw-r----- 1 0 2005-03-31 23:59:38.000000000 +0000 2005-apr
> -rw-r----- 1 0 2005-09-30 23:59:38.000000000 +0000 2005-oct
> -rw-r----- 1 0 2006-03-31 23:59:37.000000000 +0000 2006-apr
> -rw-r----- 1 0 2006-09-30 23:59:37.000000000 +0000 2006-oct
> -rw-r----- 1 0 2007-03-31 23:59:37.000000000 +0000 2007-apr
> -rw-r----- 1 0 2007-09-30 23:59:37.000000000 +0000 2007-oct
> -rw-r----- 1 0 2008-03-31 23:59:37.000000000 +0000 2008-apr
> -rw-r----- 1 0 2008-09-30 23:59:37.000000000 +0000 2008-oct
> -rw-r----- 1 0 2009-03-31 23:59:36.000000000 +0000 2009-apr
> -rw-r----- 1 0 2009-09-30 23:59:36.000000000 +0000 2009-oct
> -rw-r----- 1 0 2010-03-31 23:59:36.000000000 +0000 2010-apr
> -rw-r----- 1 0 2010-09-30 23:59:36.000000000 +0000 2010-oct
> -rw-r----- 1 0 2011-03-31 23:59:36.000000000 +0000 2011-apr
> -rw-r----- 1 0 2011-09-30 23:59:36.000000000 +0000 2011-oct
> -rw-r----- 1 0 2012-03-31 23:59:36.000000000 +0000 2012-apr
> -rw-r----- 1 0 2012-09-30 23:59:35.000000000 +0000 2012-oct
> -rw-r----- 1 0 2013-03-31 23:59:35.000000000 +0000 2013-apr
> -rw-r----- 1 0 2013-09-30 23:59:35.000000000 +0000 2013-oct
> -rw-r----- 1 0 2014-03-31 23:59:35.000000000 +0000 2014-apr
> -rw-r----- 1 0 2014-09-30 23:59:35.000000000 +0000 2014-oct
> -rw-r----- 1 0 2015-03-31 23:59:35.000000000 +0000 2015-apr
> -rw-r----- 1 0 2015-09-30 23:59:34.000000000 +0000 2015-oct
> -rw-r----- 1 0 2016-03-31 23:59:34.000000000 +0000 2016-apr
> -rw-r----- 1 0 2016-09-30 23:59:34.000000000 +0000 2016-oct
> -rw-r----- 1 0 2017-03-31 23:59:33.000000000 +0000 2017-apr
> -rw-r----- 1 0 2017-09-30 23:59:33.000000000 +0000 2017-oct
> -rw-r----- 1 0 2018-03-31 23:59:33.000000000 +0000 2018-apr
> -rw-r----- 1 0 2018-09-30 23:59:33.000000000 +0000 2018-oct
> -rw-r----- 1 0 2019-03-31 23:59:33.000000000 +0000 2019-apr
> -rw-r----- 1 0 2019-09-30 23:59:33.000000000 +0000 2019-oct
> -rw-r----- 1 0 2020-03-31 23:59:33.000000000 +0000 2020-apr
> -rw-r----- 1 0 2020-09-30 23:59:33.000000000 +0000 2020-oct
> $
>
> Each leap second occurs halfway between a pair of lines above
> (the March and September options have never been used), and
> all have been positive.
>
> Bear in mind that UTC and Atomic Time had already parted company
> by 10 seconds before the start of leap seconds, so we're running
> 37 seconds slow, rather than the 27 shown above.
>
> > > Isn't this info "global" (i.e. not specific to particular time zones)?
> >
> > It is specific to a particular *time*.
>
> Yes, 23:59:60 is inserted into UTC, so it will have occurred at
> around dinner-time in the US (for those who eat "lunch" around noon).
>
> Cheers,
> David.
>
>

-- 
Thank You

Robert M Tonkavich
989-205-2683

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


#229207

FromAndrei POPESCU <andreimpopescu@gmail.com>
Date2020-12-02 11:10 +0100
Message-ID<Bhxfc-13X-9@gated-at.bofh.it>
In reply to#229195

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

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

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


#229187

FromDavid Wright <deblis@lionunicorn.co.uk>
Date2020-12-01 01:50 +0100
Message-ID<Bh21H-6Sw-1@gated-at.bofh.it>
In reply to#229185
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.

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


#229181

FromMichael Stone <mstone@debian.org>
Date2020-11-30 19:30 +0100
Message-ID<BgW5X-3nZ-7@gated-at.bofh.it>
In reply to#229178
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. 

[toc] | [prev] | [standalone]


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


csiph-web