Microsoft warns of bugs after nation pushes back DST switchover The decision last month by Chilean leaders to delay a switch to Daylight Savings Time (DST) by a week could cause headaches for some Windows users if they don't implement the workaround outlined by Microsoft. The Chilean government on August 9 announced it was moving the start of DST by a week, from September 4 to September 11 …
I'm not sure how it is done, but I'll bet it is a "data file" somewhere in the Windows filesystem. Maybe in a file combined with some other somewhat related data, but something they could easily update. It is absolutely not hard coded into binaries. No one would do that.
The problem is the short notice. Even if Microsoft was notified of this the minute the government made the decision (and you can bet they weren't, because obviously no one making this decision thought through the consequences) they probably have enough change control layers that rolling out an update to the timezone data files in less than a month is not feasible. They may have some bypasses built into that process for a currently exploited zero day, but they aren't going to do that for a mess a government creates for itself.
Given the long and storied history of time zone / dst screwups in computers over the decades, creating a process where you can rush through updates due to the silly whim of a government to change their time zone policy with a few weeks notice would be stupid. I will fault Microsoft for many, many things, but not this.
It's just a set of Registry values in HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Time Zones\<ZOne name>
The full zone info is stored in a 44 byte TZI structure in each zone's entry
The problem is that Chile doesn't have its own zone entry, it is considered to be under "Pacific SA Standard Time."
It's probably time that MS created a separate Zone entry for Chile considering the number of times they have changed. That's easy enough to roll out with the next update, but every machine in Chile would need to have it's regional settings changed to the new zone.
The problem is that Chile doesn't have its own zone entry, it is considered to be under "Pacific SA Standard Time."
And that's probably not Microsoft's fault, I'm guessing there is an international standards organization that specifies Chile is part of that timezone? Now I suppose Chile could have fought in the past for having their own time zone just to make this easier, but that would have required they foresee wanting to go with different DST settings tha the rest of their zone.
With various states in the US going their own way, and even some counties within states going in different ways, time zone data is only going to become more unmanageable.
Maybe we need a DNS extension using TXT records that can specify custom timezones? Then a government can manage those from their top level domain, i.e. the US would have one for each state, and the states could delegate that info down to the county level. So if you configure your OS to point at tz.county.state.us.gov it'll grab the necessary data and cache it, and check however often the expiration is set for (a week or a month I guess) to see if it has changed. If there is no DNS entry it will use the currently installed datafile for that location.
I think we're moving beyond trying to centrally manage timezones. Could it be hacked? Its DNS so sure, but there are far more tempting targets for DNS hacking than making everyone late for meetings.
Time-zones are a very complicated problem to solve, and that approach has been ruled out a long time ago, because time-zones, DST observance, and territories are an overlapping set with no hierarchical arrangement: even your “simple” US example is thwarted by the Hopi Nation lands located in the State of Arizona (the former observes DST, the latter does not).
Having debugged a lot of date/time code over the years, I'm going to say that whether or not Microsoft issued that fix on time would be largely irrelevant. By default, databases store UTC for DATETIME unless you go out of your way to be an idiot, so DST is invsible to these. The issues are in calculations and presentation on those stored dates, and that’s where hackery begins.
I can guarantee that a huge number of developers will have hard-coded the DST changeover dates in their code - especially if they were using Java, whose date libraries are historically so bad that they encourage hand-rolling of alternatives. (Yes Jodatime, now java.time, is acceptable, but it took nearly two decades to become standard!)
Calculating durations and repeating events that cross the DST changeover is something I’ve rarely seen done right first time, and often the “second time” fix is something like “if (start<'hardcoded_DST_changeover_date' && end>'hardcoded_DST_changeover_date') ...” that kind of code is just waiting around for something like this to happen.
The problem is that when you made a recurring international meeting for "10AM Monday local time", what 10AM was that? The old 10AM, when all the other people will be attending, or the new 10AM, after your weekly 9AM meeting?
When you start work at 9AM, are you authorized to use the secured database? That authorization starts at UTC, mapped to the olde DST schedule.
Like the man said: devices could report incorrect times in the OS and applications, scheduled tasks may not run when expected, and timestamps on transactions, files, and logs will be off by an hour.
There's a million things like that. Unscheduled DST changes are never just a "data file update".
Updating the time zone is just a file, well actually not quite, but someone else has pointed out that Chile shares time zone data with other regions that didn't do this. Even if it was just them, though, there'd be problems. So Microsoft rushes out an update which updates just that file. Now everyone in Chile needs to install it. In two weeks. You don't get that universal response when it's an actively-exploited zero day. You're not going to get it here either.
So some machines have the patch and others don't. Say hello to lots of computers disagreeing about what time it is, and therefore what time any other reference is talking about. Systems that work by sending times between them will end up with answers that are an hour apart, and that's if the programmers have been careful only to ever use UTC for internal storage. If they ever use local time, even temporarily, except when processing user input, they can have even more bugs. This also makes Microsoft and everyone else release an emergency patch just to get into this state, which takes time and effort.
Not the kernel. It has no real knowledge of time except for UTC when it last got booted, and it checked the RTC in the BIOS. Later on in the startup process, a network ping will tell the user based systems what the actual time is, and apply whatever timezone setting the user has chosen. Not always perfect, especially if you have inconsistent data as seems to be the case here. I don't think this is an MS issue, if Chile had made the decision to be part of of block of countries, rather than be a single entity, then that is now their problem.
Be careful. It's labeled by largest city, so it doesn't mean only Chile is in there. I think it is this time, but that doesn't always hold. For example, if the U.S.'s proposal to go to permanent summer time goes in, the tzdata is going to have to change because right now, Canada uses tzdata files with American city names, so unless they do the same, they'll need to change files and everyone in Canada has to start using the new Canadian files. If other countries were included in the America/Santiago file, they didn't make this choice and would have been affected as well.
It depends on whether they use a database with a lot of copied zones or a simplified one that doesn't use duplicates. If you're using the more basic one, then except for the Atlantic provinces and Newfoundland, they use the largest cities (New York, Chicago, Denver, Los Angeles). Anything that has hard-coded these labels will need updating. Probably most Linux installations use the full TZ database. Many embedded ones use the smaller one to save on storage, so they won't be as lucky.
"Why does Microsoft make such a big deal about updating a data file?"
Because although updating the file is easy in principle, half your user base isn't going to do it, some unknown population of third-party applications will screw up because their programmers had never heard of using UTC internally, and still others will screw up because the distance between UTC and local has changed in between generating the UTC value and the time it actually refers to.
DST is a god-awful mind-fucking mess even when it is well-defined. Actually changing DST is stupid. Changing it within a week or two of the changeover date is self-harm.
i don't think the client devices (including phones and MacOS and other OSes) will be as badly affected as the servers, these may have transactional time stamps that may have legal consequences if they are incorrect.
And don't forget all those IoT devices that may end doing weird stuff on not sending their spy data off to Samsung correctly, god it could be really bad.
Ask yourself why most countries that attempted to stay on DST reverted their decisions - i.e. Chile, Russia - and why countries in North Europe decided to end DST. Because the fact that birds start chirping earlier in Summer is a lesser problem than going to bed when it's not yet dark enough, and have dawn too late in Winter.
"is a lesser problem than going to bed when it's not yet dark enough, and have dawn too late in Winter."
In Northern Europe during winter, dawn is too late whether you're on DST or not!
The real problem is that while humans evolved, and for many millennia since civilised society existed, humans have worked to a daylight schedule, working more in summer and less in winter at higher latitudes. Industrialisation and corporate culture forcing people to work fixed schedules throughout the year is the root problem here. Without that, there would be no need of DST, people would have different schedules in different seasons, and work whatever time works for them as long as the work gets done. (That, by the way, is a natural extension of going back to home working) .
That, or have everyone migrate by 20 degrees latitude every autumn/spring
The really weird part is that, at least in the UK, one of the most vocal groups opposed to ending DST is farmers, who are also one of the few groups who still overwhelmingly work to a daylight schedule (or at least to the needs of animals and crops, which amounts to the same thing) and not the clock.
The birds chirp based on the light level not on what time humans decide to call it. Our time systems contain a the concept of midday/noon when the sun is nominally at its highest point. To shift your clock around so that physical midday does not match timed system midday seems a bit contrary. Granted where you are mucking around with DST it means you have the convenience of having more evening light without changing your working hours from '9to5' to '8to4'. If you are not going to use DST then use a time zone the gives you the best match to midday and just sort out your waking hours as appropriate.
UTC does not observe the so-called Daylight saving Time. Nothing is actually saved. Especially not with the resulting confusion twice a year.
Mucking about with the time zones, either results in gaps in the 15 degree separations in the time zones. or overlaps.
No DST, no computer confusion. No wondering what time it is for that meeting, somewhere else. Are they on DST, or Standard time? Do they change with everyone else, or days, weeks differently.
Stop it already. Too much energy is being spent twice a year, when a simple fix is at hand. Just stay on standard time the year around.
They do moving the Avebury stones for British summer time
(Of course they had to pretend it was a joke when news leaked out)
"*Zulu time defines the baseline as the time “Zulu” was shown on BBC1 on Christmas Day 1980, that being stated as 00:00:00 Zulu time."
I realize (hope?) you were probably joking, but just for clarity of readers who might not know better, this is not the case. It is most likely based on Sandford Fleming's system, but in any case came from making official already existing usage in the armed forced of NATO, specifically the two most important (in practice) the UK and the USA.
Z (Zulu, from the NATO phonetic alphabet) is UTC (Historically, UT1/GMT), A through M (J - Juliet is skipped) are positive offsets (UTC+1, ... UTC+12), N through Y are negative offsets starting with UTC-1. Twenty-five letters used, one for each offset, and one for UTC itself.
Aviation exclusively uses it (UTC) in communication, to ensure nobody is confused about timing.
When Canada and the US changed the beginning and ending of DST, MS provided a tool to edit the time zones called TZEDIT.EXE.
"Tzedit - Time Zone Editor
Tzedit - Time Zone Editor Tzedit is a freeware utility that allows you to edit time zone information in Windows. All parameters can be edited such as time zone name and information, time zone location on the world map (MapID), Microsoft Time Zone Index, MUI strings for time zone name and Dynamic DST settings. This utility works on any version of Windows from Windows 95 to Windows 10."
https://www.southsoftware.com/tzedit.html
download link: https://www.southsoftware.com/tzedit.zip
There's an whole article about it, because a similar case already arose 16 years ago with Guatemala, and it seems that back then, there were indeed Microsoft tools to handle the situation:
https://support.microsoft.com/en-us/topic/how-to-configure-the-daylight-saving-time-start-date-and-end-date-for-guatemala-in-windows-7de59d8a-f3dd-de45-14bf-9ca3024a36c3
What happened that it's now more complicated?
My employer (security infrastructure) always uses GMT/UTC everywhere for legal integrity of data. Conversion to local time is done when it is displayed to the user.
Only poorly written software will base time decisions on local time. (Probably most of it, then.)
I feel daylight savings should be abandoned.
The airline / ATC industry also uses GMT/UTC universally because it saves lives.
Yep most software runs in gmt/utc and the sensible stuff just has an offset in the display the user sees.
Correlating log files when dst kicked in was always fun - some massive holes or duplicate entries depending on which end of the year it was.
Once everyone agreed to keep the timezone the same it was a lot easier.
DST is a massive pain the arse - timestamps should be unique right? I do not need two different 02:30s.
They are unique if you record the time offset from UTC with the timestamp (ISO 8601).
2022-10-30T01:30:00+01:00 and 2022-10-30T01:30:00+00:00 are different, unique times. (Note the clock moves back an hour at 02:00, not 03:00)
If you are not doing this, the software that generates your timestamps is broken.
And there was the example cited earlier, of scheduling a meeting at "local time X". What the Chilean government have effectively done is change the meaning of that data after the fact. This isn't something that your meeting software will even be aware of unless it follows the local news.
Well, yes, but UTC has its own problems as it has leap seconds, which Google cope with in a non-standard manner by 'smearing' the clock over several hours to avoid discontinuities in the logs etc. See also Google Cloud:Making every (leap) second count with our new public NTP servers
We could do with a 'monotonic' time standard for use by computers which is converted to local time for display purposes. While UTC is fine for most stuff, by definition, it can have leap seconds added or removed as it attempts to stay roughly in synchronisation with the Earth's rotation rate, which is variable.
There isn't an official monotonic time. TAI comes close, as an aggregate of several hundred atomic clocks, but it is worked out statistically 'after the event', so there isn't a TAI timeserver as such.
Meta::cpan - Time::Monotonic - A clock source that only increments and never jumps
Blargh (2010-09): gettimeofday() should never be used to measure time - Monotonic timers
If you really want to get into the details of time standards, astronomers have been considering this for decades, and I can heartily recommend Steve Allen's web-pages.
POSIX already requires that zoneinfo offsets handle offsets of seconds.
Starting from the top (there is a lot of depth), the initial web-page is:
UTC might be redefined without Leap Seconds
NN
"The airline / ATC industry also uses GMT/UTC universally because it saves lives."
I'm really, really sure that I never, ever bought a plane ticket using an UTC timestamp. So it's not using it "universally". It's using it "internally". And if it doesn't have the proper, up-to-date information to convert UTC to local time to display it accurately, then people are going to be mightily confused and will miss their flight.
As other people have pointed out, if I schedule a meeting for 14:00 London Time on a particular date, and Liz Truss changes our time zone rules, Liz Truss has changed the time of our meeting.
Or if the meeting is actually in Scotland, and Nicola Sturgeon changes Edinburgh time to not be the same as London time, then ...
Or a sysadmin: after being bitten by it, I've forbidden to crontab anything between 2 and 3am,
For once, I disagree with the XKCD mouseover.
Case in point: between 1584 and 1752, there was a 10+ day mismatch between the British and continental calendars. While we happily accepted the new rules made up by Pope Gregory, you guys over the Channel and your colonies further west were a bit slow to accept he was right. And yet, History never bothers to explain that things happened at different dates during that period.
IIRC there were riots for various reasons to do with the missing dates.
1) people paid monthly rents on a specific day - and suddenly they were getting fewer days for their money.
2) some people were apparently convinced (conspiracy theory?) that their lives had actually been shortened.
My UK central heating timer is standalone. It came with time (and presumably date) apparently preset in the factory. It has some sort of internal power back-up - whereas the earlier model had a user battery that was invariably exhausted when needed. It knows when the clock should change in the UK - so presumably hard coded.
At the moment one less clock to alter twice a year*** - but there are often murmurs of about a new approach to DST.
***Most of the clocks in the house are MSF controlled - which dies not guarantee a smooth transition as they tend to save battery power by only checking with MSF occasionally during a day. The MSF standard possibly should have been UTC - with predictive indicators in the transmission that a change would be needed. However that would probably have upset the use of the sequence of sixty one second transmissions to encode the date and time for each minute..
The MSF standard possibly should have been UTC
MSF should be monotonic, with a field to show the total of leap seconds since the epoch, to allow calculation of UTC, and another field to show the civil time offset from UTC. That way, you get a useful standard time, with built in data to allow calculation of the current civil time ( current UTC with or without 'summertime' ).
Distributing civil time as a time standard is not helpful.
Civil time is defined by the Earth's rotation with respect to the Sun, which is variable, and gently (on a long term average) slowing down. Our (mostly atomic) time standards keep time better than the Earth's rotation, so while it makes sense for civil time to be in lock-step with the day length, it does not make sense for a distributed time standard to be based on the Earth's rotation. Using UTC does not solve the general problem because it incorporates pretty much randomly occurring leap seconds*. Using a proper standard with a known conversion to UTC does.
*As someone pointed out, trying to predict when a leap second will be needed to keep UTC in step with the Earth's rotation is like trying to predict the weather.
I just use unixtime for everything and have zero problems because I never interface with other humans or require crontab... In all seriousness though I do use unixtime in most custom logging I do with so much less hassle for devices distributed across time zones, and then I had to work with a company that used JMP to look at various device data (defining their epoch in seconds since a hundred years ago or something I can't even remember bc it's so arbitrary and specific to the program) and a bunch of devices with real time clocks that use an epoch starting in 1980. Ugh!
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
