Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.debian.user > #229178 > unrolled thread
| Started by | Charlie Gibbs <cgibbs@surfnaked.ca> |
|---|---|
| First post | 2020-11-30 19:10 +0100 |
| Last post | 2020-11-30 19:30 +0100 |
| Articles | 13 — 9 participants |
Back to article view | Back to linux.debian.user
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
| From | Charlie Gibbs <cgibbs@surfnaked.ca> |
|---|---|
| Date | 2020-11-30 19:10 +0100 |
| Subject | Re: 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]
| From | Robert Tonkavich <rmtonkavich@gmail.com> |
|---|---|
| Date | 2020-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]
| From | Greg Wooledge <wooledg@eeg.ccf.org> |
|---|---|
| Date | 2020-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]
| From | deloptes <deloptes@gmail.com> |
|---|---|
| Date | 2020-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]
| From | John Hasler <jhasler@newsguy.com> |
|---|---|
| Date | 2020-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]
| From | David Wright <deblis@lionunicorn.co.uk> |
|---|---|
| Date | 2020-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]
| From | Stefan Monnier <monnier@iro.umontreal.ca> |
|---|---|
| Date | 2020-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]
| From | John Hasler <jhasler@newsguy.com> |
|---|---|
| Date | 2020-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]
| From | David Wright <deblis@lionunicorn.co.uk> |
|---|---|
| Date | 2020-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]
| From | Robert Tonkavich <rmtonkavich@gmail.com> |
|---|---|
| Date | 2020-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]
| From | Andrei POPESCU <andreimpopescu@gmail.com> |
|---|---|
| Date | 2020-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]
| From | David Wright <deblis@lionunicorn.co.uk> |
|---|---|
| Date | 2020-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]
| From | Michael Stone <mstone@debian.org> |
|---|---|
| Date | 2020-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