[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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



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.


Reply to: