tz database community up in arms over proposals to merge certain time zones The time zone database hosted at the Internet Assigned Numbers Authority (IANA) has been updated following threats, earlier this year, of a fork over a proposal to merge time zones. The update, the 2021b release of the tz code and date, was published over the weekend and omits some, but not all, of the issues that have caused …
/usr/share/zoneinfo/ is 3528kB so no, it is absolutely tiny on a twenty year old desktop, laptop or server. On embedded systems this was often an issue. Every year it becomes an issue less often as embedded systems grow bigger.
Twice a year at the transitions between UTC and Bergholt Stuttley Time my TV changes the time by one hour in the wrong direction so it always gets the time wrong by one hour. I am sure this is because someone trimmed the zoneinfo database or rolled his own. Microsoft infamously got DST wrong once: they set local time back one hour at 01:00 local time - then again every hour until people set the RTC to the correct time through the BIOS.
Time is surprisingly tricky and lots of PFYs throw themselves into the common pot-holes because they think they are Time Lords. Although it is theoretically possible that a standard way to reduce the size of zoneinfo would reduce errors I am convinced that the exact people who should use it will not bother to RTFM.
Amen brother! I have to vaguely help mantain a database of old newspapers, and the contortions I have to go through to support sorting old dates is horrendous. It's especially tough in Europe where the calendars weren't unified for a long long time, so getting dates to agree between different countries is seriously tough work.
For embedded systems maybe they could create a make option that specifies a time horizon - i.e. "make EPOCH=2020" and it doesn't include any data prior to the year 2020.
For an embedded system like a wireless router that never has reason to reference to times earlier than when it goes on sale, that would seem a reasonable thing.
Why would anything embedded want anything other than UTC?
Being slightly serious though - what micro embedded devices need to report local time to a user without some other device doing the display and interaction?
I suppose there might be a few things like thermostats which have local interaction with a clock involved, but... Have a "DST" toggle button?
Because modern routers have UIs designed for ordinary people to use them. If Linksys or whoever is selling a router with parental controls so you can keep your kids off the internet after 10pm, the typical person is going to expect that to mean 10pm where they live, not 10pm in Greenwich.
And as you say thermostats, smart TVs, home alarm systems, or heck in fridges these days. The need for embedded systems to understand time zones is only increasing as more and more devices become "smart" (whether needed or not)
But unless they need to refer to times in the past (before they were first sold) they could use a much more streamlined tz datafile.
Many routers allow you to connect to them via a web browser. Probably there's a way to handle this with a Javascript program the router runs (I know nothing about Javascript and intend to remain ignorant of it) but it would be easiest if the router just supported timezones - and DD-WRT for instance already does at the OS level and a lot of commercial router software is based on that.
FWIW, if you're prepared to have a little bit of JavaScript in the frontend, it's possible for a web application to have the backend work with only UTC times and the frontend display locally correct times, without needing a copy of tzinfo server-side. I have done it (in an application that already needed JS for other reasons anyway).
Of course that doesn't suffice for complicated things where you really do care about the local time zone in the backend. e.g. if I'm scheduling a thing to happen at 9am every day, I probably don't want it to suddenly start happening at 8am or 10am when DST flips over, so the backend will need tzinfo.
The software the router runs all has to know about that. If you set up a filter, then:
1. The interface must know your time zone so you set it at local time.
2. The filter program, which is likely a different process, needs to know about your time zone.
3. The log the user sees has to know about the time zone.
Given that most of the routers out there are running something with a Linux core which can handle time zones and has sufficient storage to store the relatively small database, why not have the OS handle time zones like any software on a normal computer would do?
"I suppose there might be a few things like thermostats which have local interaction with a clock involved, but... Have a "DST" toggle button?"
No, please don't do that. Such things confuse a lot of people (I.E. which position should this switch be set to now? Was it set right the last time?). If it's smart enough to know what date and time zone it is, it can switch that automatically unless configured not to. Having to change a dumb clock is fine, but having to change something which is smarter and probably not obvious that it has a clock is just a pain. If we have to do DST (and we really don't), then the computer should do the adding and subtracting.
ISTM that any "smart" (i.e. Internet-connected) device, could query a web service to get its timezone data. The location (country/state) could normally be determined from IP address, and overridden by the user if necessary.
It could either be a shared service, or something provided by each manufacturer for their own devices. If the service stops responding, then stick with the last-downloaded info.
Advantages:
- No hard-coded database
- No need to perform firmware updates when the location changes its timezone rules
- Easier to support a single TZ service indefinitely, than providing ongoing firmware updates for all device models ever produced
- Time zone data can be maintained in whatever granularity makes sense, without affecting device resources
Disadvantages:
- Privacy. But you already lost that battle as soon as the device makes any sort of call-home over the Internet.
Simply downloading the TZ data for your time zone, during setup, would work just fine, with a micro- controller-based embedded device that has a simple web interface. The embedded device would then use the data to do its time conversions on its own internal clock and display the correct(ed) time.
(for offline setup maybe a fallback system where you manually enter things like UTC offset and DST start/stop etc.)
I've done some experiments with Arduino with a web interface. With some creativity, you could make it all fit in the NVRAM, though it's probably a LOT better if you use a device with larger than 32k for code space.
A slider that has one end labelled DST isn’t a complex interface, and it would only be needed on the few devices with a clock. My old thermostat (just about digital, but certainly not connected).
(Apologies I did say toggle button, wasn’t what I was thinking)
It’s only relevant on a device that does some time based switching, and displays a basic time based interface - old thermostats are the only example I could come up with (never had a cooker or microwave that knew what day it was).
Anything using a web interface has a better way to configure stuff (use the web UI - import a snippet of the TZ dB when the user configures you (only need the forward data for this TZ after all).
"A slider that has one end labelled DST isn’t a complex interface"
I don't know about that. I remember distinctly a device which had time zone settings in two menus. The first required you to select your UTC offset. That for me was easy, but I doubt the general public who would also be using this device would automatically know that. The second: daylight saving time disable/enable. When I first saw that, I assumed that meant that I should select whether my country did DST. As far as I knew, my time zone contained some countries doing DST and some countries not, with all those observing it starting on the same date. I quickly realized how that was a stupid assumption, as there are time zones that don't have just two categories. I then assumed that the switch would change the clock by an hour, so I should just switch it when the clocks change. I tested it and it didn't.
Only later did I discover that there was an NTP update running, and I was supposed to switch it whenever the clock changed then wait for NTP to get UTC again, reflect my switch,and update the clock accordingly. By the way, that's skipping the part for many non-developers who aren't paranoid about getting DST wrong (XKCD) and don't know whether "enable" means summer or winter. Those who get it wrong have the clock wrong by an hour all year long. Is a "select your location" thing really so tricky? I ended up disabling NTP and just remembering to change the clock.
Why would anything embedded want anything other than UTC?
In some cases you might have to deal with outside systems that need accurate time stamps. If those systems use local time and NOT UTC (UTC would be sensible, try telling THEM that) then the embedded device will have to "do things THEIR way" and get the time zone right because the existing system and customer base do things that way and they're big and you're not. Or something like that.
So you provide a screen to use tz data to set the time zone just like you do when you set up a personal computer. On Linux it's not too hard, right? [I manually filtered North American time zones and stuck them in a drop-down combo box, one that's easy to change if it ever needs to, so the interface would not be unnecessarily cluttered with 100 time zones or something]
My cooker has a clock that should, sometimes, display B.S.T. but to my knowledge never has. It has automatics such as a countdown alarm and settable cooking programmes so having the "correct local time" really should matter at least a little though realistically not so much as one would at first thought imagine.
It never has had. In the unlikely event that I need to programme a meal, I would simply work out the B.S.T. to U.T.C. corrections. It's hardly rocket surgery.
I'm not entirely sure whether the device counts as an "embedded system" or whether it is more in the nature of the relays that drive my washy-machine but with a clock added as a trigger. It's pre-Win-XP tech so I rather suspect the latter.
Uhhm, I'm also fairly sure that the time displayed is not, in fact, G.M.T. nor any recognised time-zone as I have long ago forgotten how to set it. I really should rediscover this procedure.
Paul Eggert has argued that the changes will bring "equity" and be "fair" to countries such as Angola. When asked about why it is necessary to make these breaking changes now he has referred to private emails, outside forces and claims that it is "relatively urgent for us".
I believe these posts from Eggert captures the political motivations behind his initiative:
https://mm.icann.org/pipermail/tz/2021-September/030672.html
https://mm.icann.org/pipermail/tz/2021-September/030721.html
https://mm.icann.org/pipermail/tz/2021-September/030732.html
https://mm.icann.org/pipermail/tz/2021-September/030740.html
https://mm.icann.org/pipermail/tz/2021-September/030742.html
I am left with the impression that Eggert is being forced by someone, possibly his employer at UCLA, to carry out these breaking changes while ignoring the concerns of people from Microsoft, Oracle, .NET, Java, PHP, Tcl and PostgreSQL.
See https://mm.icann.org/pipermail/tz/2021-June/030194.html (thread)
Perhaps with the minor detail that those separate timezones exists because of decades of effort in documenting historical data (pre-1970). If I understand things correctly, Eggert has decided - in the name of "equity" - to deal with the situation by simply tossing out that historical data so he can get rid of those separate timezones. He argues that since he has already done this to smaller (African?) countries, it should be fair to do this to European countries.
Plenty of people have asked him to reconsider as his actions will break existing systems, but he seems to be 100% committed to ignoring such pleas... because "equity".
Eggert insists that this is not a political decision, but I disagree - this is a geo-political issue and the outcome should not be for Eggert to decide by himself.
I seem to remember once stumbling on a section of the timezone info where someone had gone to great lengths to define "london time" and "GMT" to take account of the various different positions of the Greenwich meridian in the 1700s and 1800s (it moved several times by upto a few metres each time as the methods for definiting it was refined by successive Astronomer Royals) and then preceded by the time as defined by a sundial somewhere which was considered to be the reference before then.
N.b. this sort of change "by dictat" seems to be exactly the sort of thing that will spin off an activity to do it in the way it ought to have been done. Sounds like its time to fork time!
"equity" "make tzdb fairer again". Blchggg... where's the pink liquid... (see icon)
There's no crying in baseball... (yeah we all saw 'League of Their Own' right?)
- and -
There is NO POLITICS IN COMPUTING !!!
what a ROTTEN way to swing a WRECKING BALL into a world-wide project to maintain a LIST OF TIME ZONES
Oh ffs, is it really necessary to merge zones and delete pre-1970 changes? We're not running on mainframes with 64kwords of memory any more. Utterly pointless changes from an arsey developer who WONTFIX anything he's philosophically opposed to regardless of arguments or consensus to the contrary. Oslo isn't even in the fucking EU, it's a separate political entity with control of it's own timezone and could easily potentially diverge again in the future.
Yes, but DST rules are the same throughout the EU - forward on last Sunday of March, back on last Sunday in October, both at 1am UTC.
This may change soon, it is been due to change next year for about the last 5 years, one of these times it might actually happen, and if it does, it will change throughout the EU. Norway, UK, etc would need to make there own decisions about whether to follow the EU in making these changes.
If I remember correctly, I think the European Parliament voted to abolish DST, but it was left to member states how to act upon it. Now the member states are stalled in discussions about which country will make which time, summer or winter time, permanent. It might just turn out to be easier to keep things as they are than to devise a plan which all member states can agree upon. Brexit with Ireland still in the EU hasn't made things easier, either...
"And the EU is spread over at least five time zones with Greece on one end and Cabo Verde on the other."
And parts of the EU spread even further around the world than that: France isn't just "metropolitan France", for example. In fact, perhaps that's the current "empire on which the sun never sets"? ;-D
the EU is spread over at least four five time zones with Greece on one end and the Azores Cabo Verde on the other.
Much more than that. Outermost Regions are part of the EU.
This is the sort of "breaking userspace" change that used to break Linus' patience. Many of the sweary rants were directed at repeat offenders on that front.
If others are relying on you, don't "move fast, break things." Use care and deliberation, don't honk off the folks downstream.
I kinda get what they want to do here, there are lots of 'different' timezones in tzdb which for a lot of purposes aren't different at all. I just recently had to write code handling just that. It was all about times in the future and needed to take time differences and daylight savings into account. And it simply was more complicated than needed because Europe/(Amsterdam/Berlin/Oslo/Paris/..) are considered different zones because things where different over 50 years ago. So I sure can see the case for merging zones which are identical right now.
However, I can also see how there are perfectly valid uses which do need the historical differences. So perhaps we need two databases, one that is complete with all history for people who need it, and one with just the current data (or maybe just the last 5 years or so) for people that only need to deal with recent and/or future dates and times.
I see the political issues with the current proposal which basically drops Oslo and keeps Berlin (I even agree with that being wrong). I also understand the desire to reduce the number of zones because so many of them have been functionally the same for a long time now. To me it seems that both of those can be satisfied by having two databases. The database with the 'recent' zones could be created by just merging all zones which have been identical in the last 5 years. A strict rule like that should go a long way to avoid the politics. It would also leave the current database intact, with all history in there so nobody needs to feel left out.
But maybe I'm too optimistic about the politics involved, that's possible.
Your wish is their command. Except the rule is timezones that are the same since 1970 are merged, and the second "database" is maintained in the source and available at the flick of a command-line switch to those who need it. (Me.) What they are trying to do is enforce that rule - with the consequence that 1940s Oslo now looks like Berlin...
I'm not clear on how this works in general, but BBC World Service radio (Europe anyway) broadcasts in English and in Greenwich Mean Time twelve months of the year. I suppose if you're halfway round the globe then converting that to your local time needs knowing how far away Greenwich is and whether you have local daylight saving, which you probably know, but it excuses you knowing whether it's daylight saving in Greenwich, because how would you.
So in this sense at least, Greenwich Mean Time exists while London (except the BBC) is not using GMT.
So, the UK will need its own entry since in 1970 the 3 year "all year BST" experiment was in progress!
(I remember it being at primary school in what is now Cumbria then ... we went to school in pitch black during the winter, school was only ~1/2 mile away but along a busy road with no pavements so parents arranged rotas to take us by car etc and the habit of walkign children to school was lost)
How about a new "modern name" column, and all the different timezones in CET could have "CET" as the modern name and would appear as one item in a user-facing timezone list. That's probably workable.
But if the solution to your problem is two of something, then you usually end up with two problems later on.
CET WET
Reminds me of a conversation with the lab engineers of a certain Unix vendor back in the 80s. Can't remember how the conversation started but
Me: Why do you call the timezone for the UK, WET
LabEng: Coz that's what you call it
Me: No we don't
LabEng: you do
Me: I live there I should know
LabEng: Well what do you call it
Me: GMT
LabEng: that's not its name.
Me: Well what do you call your timezone.
LabEng: MST
Me: What's the full TZ= variable setting?
LabEng: sounding exasperated TZ=MST7MDT
Me: And the 7 is?
LabEng: still sounding exasperated the 7 hours after GMT
Me: precisely, and where is the Greenwich in Greenwich Mean Time? Let's face it, we're not talking about the one in New Your are we.
LabEng: Ah... So you actually use GMT time as your own time too
Me: Errr Yes, well at least in winter, in the summer we have British Summer Time, which is just another phrase for "it's raining again"
As the man page for spell used to warn
Warning! the British spelling was also done by an American.
Taking DST into account? How the heck do you predict the setting for DST past the recess of the current legislature? They can change DST rules at the drop of a gavel, so "future" is far from guaranteed.
Somehow reminds me of how (IIRC) MSFT finally patched Windows to recognize 2000 as a leap year in about November of 1999. The complaints that drove this patch were from financial firms that had to deal with dates in the future (like, loan payments).
Time is tricky enough without politicians and programmers. We will have both until the dolphins take over.
...and two databases.
As many here will recall in 2007 the US changed their DST rules. They'd announced the change in 2005 but Microsoft didn't release updated timezone 'patches' until after the end of US DST in 2006. Effectively there were two timezone databases to consider: one before and one after the change.
Calendar/diary entries (for example) that were made before the patches were applied were not automagically shifted to the correct time (though, to try to be fair, MS did release a tool to try to identify and fix the times of appointments). Added complications arose because external appointments might come from an already patched system to an un-patched system or vice-versa and then none, one, or both (or more, for large meetings) systems might be patched by the time of the appointment.
I really don't think having two tz databases is a great idea. Different versions are bad enough.
I also remember that train and flight timetable boards were distinctly unreliable in Sydney when Aus decided to tinker with the start of DST (usually October) and have it start in August 2000 to avoid disrupting the Olympics. That went well...
Icon: When the big hand is pointing straight up and one of the little hands is pointing somewhere between the four and the five then it's... difficult to work out what's going on. --->
yes, this goes back to the 1800s when time zones were invented. With time zones, people could still use a clock and the sun (and maybe a rooster) to determine when to wake up and do their daily work [mostly agrarian and support of agrarian work] and when to sleep, but ALSO the train schedules were synchronized well enough to allow the railroads to schedule use of single-track rail lines (and avoid train wrecks). It made so much sense the entire world adopted the idea.
Besides, can you imagine how the TV schedules would be messed up if we were all on UTC? You'd still have "time zones" but they'd be based on when the morning shows and evening news comes on in your area...
When i was in the Navy, if we deployed longer than a few days, on the sub we'd switch to "Zulu Time" and operate on UTC until we came into a scheduled port, at which point we'd switch to the local time zone. It avoids switching the logs around every time you cross into a new time zone. Meals and watch rotation was all time based and so it was done in a sensible way. On a sub there's no night or day but the meals change. That's how you know what "time of day" it is. And watch rotation often throws you into 18 hour days (6 on, 12 off), which makes things that much more "interesting".
Yeah, timezones came about directly and simply to allow readable/useful timetables to be printed. Up till then, every town had its own time, set correctly. Now, every clock is wrong.
Oxford still has its public clocks set to correct time. IIRC, 2 mins behind London/GMT. A lovely nod to history, and to eccentric boffinry precision.
> What is GMT?
> Greenwich Mean Time or GMT is the time displayed by the Shepherd Gate Clock at the Royal Observatory in Greenwich, London. When the sun is at its highest point exactly above the Prime Meridian, it is 12:00 noon at Greenwich.
> GMT is is not affected by Daylight Saving Time (DST) clock changes.
> The Greenwich Meridian (Prime Meridian or Longitude Zero degrees) is the reference point for every Time Zone in the world.
> Every 15° longitude represents one hour's difference in time: (24 x 15 = 360, the degrees of a circle). You can work out the time at every location on earth if you know how many degrees it is east or west of Greenwich.
The problematic database is not necessary. A simple GPS signal can be used to determine each locations actual time - no needless clumping involved.
And Brittania's got a solid lock on the IP - the royalties will surpass those of North Sea oil, but they will last forever. Get me Boris on the phone! This is going to bigger than "what3words".
If we throw out daylight saving time, which we can and probably should. We also have to deal with the countries that decided to have fractional time zones, among them Australia (some states at UTC+9:30), India (UTC+05:30) Canada (one province at UTC-3:30) and the weirdest Nepal at UTC+5:45. Also China's insistence on using one time zone when they're big enough to need three, and it's not even the middle one. Here's what currently happens to the map when you use the time zones as they currently exist: https://xkcd.com/1799.
Aussies have AWCT (Australian Western Central Time, +08:45) as well. Another 15-minute offset from GMT, it applies only to Eucla, a spot on the map on the SA-WA border, to put it halfway between Perth and Adelaide, chronologically as well as geographically.
Except when Adelaide is on ACDT. One country, seven time zones.
@doublelayer
IIRC the most recent DST battle in California was about getting rid of the yearly clock-setting festivals, which most people approved. Alas, major support was behind the notion of making DST year round. So kids could have the opportunity to walk to school in the dark much more of the year, and one might get a bit sleepy waiting for the feature at the drive-in movie to start. But shops and (especially) restaurants from extended "after work" hours.
(Yes, I do live in a town small enough that many kids can, and do, walk to school. Yes, the school has more than one classroom)
in 1973 the USA kept dailight savings time for an entire year. I walked to school. No problem.
In 1974 and 1975 I went to a high school that had "split session" and Freshmen had school from 12:00 to 4:30 (or something like that). I walked home in the dark during the winter. No problem.
Actually it was not THAT dark in either case. but as I recall, the cars had their headlights on.
besides, most parents are like "helicopter parents" these days, and drive their kids to school. The local private school near my house has the expected traffic jams as the expected times because of it. Fortunately there's a way to drive around it if I ever need to.
"A simple GPS signal can be used to determine each locations actual time - no needless clumping involved."
So, from London, you tell your mate in Bristol you'll phone at 12 noon tomorrow. He gets a bit pissed off when you phone 10 minutes early while he's still in a meeting. That's why "railway time" was invented :-)
"What it is" is somewhat arbitrary, depending on how certain terms are defined mathematically, what assumptions and measurements are used to determine the actual shape of the planet and of its gravity field, how accurate those measurements actually are, how many of those things things change over time, ... once the axis of the original transit telescope is too far away to touch, it's remarkably difficult to describe precisely where it (or anything else) actually is with respect to anywhere else on the planet.
While not GPS, a couple of years ago I became slightly confused by the time when we were on holiday in the Algarve and spent a day visit the far eastern end we'd never been to. Driving up beside the river that marks the border between Portugal and Spain my phone and smartwatch weree continually flipping time by +/- 1 hour depending on whether the phone had connected to a Portugese or Spanish phone tower!
We didn't lose any information. A program stopped containing it. You can look up historical time information in many places. The question is whether the TZ database needs to contain all of what it currently contains. For the same reason, the TZ database won't correctly handle the calendar switch before the Gregorian became nearly universal, but if you want to see how each country did it at different times making a big mess, you can still look that up. People tracking historical events do this frequently. It's like asking whether a textbook should contain the full text of a historical speech--if it is decided that it's not needed for the educational experience, one can still look the speech up and read it elsewhere.
1970 is very, very recent.
Living memory.
The DB is tiny. Really small.
If you want to make a shorter set of "modern" timezones, then fine. Create them and give them explicit markers for their validity - for example, CET didn't exist prior to 1981.
Don't screw around with existing historical data. Somebody is definitely using it.
Exactly! The library is supposed to handle this. Now, no more.
Date time programming is hell. This has just made it more hellish for that "some" set of programmers. If you want to deal with Oslo pre 1970s dates and time, cannot use this.
And, as far as I can see, it is not even an actual problem, really!
If anyone wants the link - https://en.wikipedia.org/wiki/Tz_database
Remarkable how simple it is. I tripped over this about 6 years ago when looking at sunrise and sunset calculations.
I can't see any need to change it, the file is small and if it keeps it simple for consumers then why not.
Trying to remember that region X got folded into region Y for no apparent reason doesn't help anyone, particularly if you need good Geography skills to figure things out, then it fails in its primary purpose. I'll take the hit of a couple of extra KB of data in the files thanks.
.
"In a nutshell, put "Europe/Berlin" or "Europe/Oslo" with a pre-1970 date into the system, and out will come an answer. But the answer will be different for each option as there was a time when the two zones were different. However, as they've been the same for the past 50+ years, the proposal was to have "Europe/Oslo" simply be an alias of "Europe/Berlin" – meaning that Oslo's pre-1970 data would be effectively replaced by Berlin's."
Nope. It's for pre-1996 dates. Before that, there may be differences. E.g. in 1983 when Germany changed from DST last Sunday in September, while Norway changed last Sunday in October.
My Rpi collection received a tz update recently.
Not only is this change risky, for any number of legacy code reasons, it is also completely unnecessary.
In recent years I have started recording ‘clock on the wall’ time in databases as well as the UTC and DST stuff in DATETIME columns as there is just too much of a fight going on in the various libraries that I have used.
Ah well...
... why don't we do away with timezones altogether? We all (*) have a device that knows _exactly_ where we are so could easily calculate a precise local time for you. Then all we have to do is indicate exactly where the event is due to occur at its local time and then everyone knows exactly when too!
So bus/train timetables would factor in the position of the stop/station and google maps route finding would know where you are starting from (and what time it is there) and compare that with the place you are going (and work out what time it is there), etc., etc. ...
There might be a few minor teething problems but I'm sure we could make this work!
It would have a couple of advantages of spreading traffic and power requirements out a bit as depending on which side of the country you are, you would be doing things at a slightly different UTC time compared to the other side.
This is a great idea! What could possibly go wrong?
(*) well, many of us and a rapidly increasing proportion of the human race.
Simplifying timezone database handling by introducing a compile time option to build a different database, one for normal use and one for historians that need actual accuracy?
What genius - now there are two databases to maintain! Ok, it's not so bad - you just have to run the full test suite twice, as well as making sure to have test cases that separate the differences. Uh... there *are* suitably complete test suites for something as important as this, yes? Especially with the sources obviously complicated by global compile flags that change the behaviour all over the place, and with the project goal of merging some of the timezones apparently touching quite old stuff with most every release, the expected results will also change with every release?
good move. Truly, this is a microoptimization (size reduction is low, and time to look up a timezone would be unaffected essentially... maybe even increased if looking up a symlink, following that symlink and opening resulting file was any slower than opening file directly.) I'd do it if nobody objected. But they are objecting, so why bother?
For ease on the time zone administrators, just add a control file and script to saying which timezones are equivalent post-1970 so you can update the post-1970 for Berlin and the script can copy the post-1970 info to Oslo etc., so users have their seperate files but administrators burden is still lowered.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
