Important note: "Senator Marco Rubio said after input from airlines and broadcasters that supporters agreed that the change would not take place until November 2023."
After that date we would no longer transition away from daylight saving time. It would not cause an immediate transition. There would be one more transition in the following year to get back onto daylight saving time. So the effective effective date is really march of 2024.
I would say the deadline is much sooner, since it becomes very necessary for some software to correctly recognize future dates correctly well before they arrive.
It's so stupid to delay for years, this should take effect immediately. There is no real sense in pussy footing about, people need to just do the work either way.
If you're rolling your own datetime object for some reason, sure. But to the VAST majority of applications, this is an "update your referenced packages" change.
> What about all the embedded systems out there, which do very important things with timekeeping?
I've written a few of those. Supporting not-DST basically comes down to unchecking the bit in the configuration where it says:
[ ] Confuse the hell out of the users twice a year.
Even if the customer themselves specified precisely how to handle the changeover once upon a time, they still get confused when it happens and the daily report has 23/25 hour entries, or the daily totaliser takes a mysterious 4% dip, or the date changes an hour earlier/later than expected etc.
I've never seen an embedded device with automatic changeover that didn't have some kind of configuration option to switch it off.
> I've never seen an embedded device with automatic changeover that didn't have some kind of configuration option to switch it off.
"Always in Daylight savings time" tends not to be the option that's offered-- either always in the standard zone or always changing.
And, the point isn't that devices can be reprogrammed or reconfigured: it's that there's a lot of them, with uneven levels of support, and difficult to go reach them all.
The day that the time shift changes is constantly in flux, since the 1960s, before most embedded software was written. If you were writing embedded software that changes time zones automatically, unless you were very dumb, you made the date of the change configurable, given that we were on DST for a few years in a row in the early 70s.
So yes it's a lot of work to find them all, but they should all be configurable to just set the next Standard Time shift to be the max(datetime).
> So yes it's a lot of work to find them all, but they should all be configurable to just set the next Standard Time shift to be the max(datetime).
The two systems at my school where time is important are old and are not likely to work correctly with current firmware, and it's unclear whether new firmware will be available:
- Our PA/bell system
- Our automatic gate opener
At my home, most things are smaller problems (I doubt the prosumer switches, etc, that I have can handle it or will be updated, but I set them to UTC) or cloud services that are likely to update. I do have a few old GPS things whose handling of localtime will probably be screwed up forever, too.
That's just off the top of my head. It'll be a big pain in the ass.
If those systems are "very old" and still correct, then that means they are configurable. We changed the dates of start and end of daylight saving time in 2006.
Right it will be a pain to find them. But once you do it should just be a config change. The date of the DST changeover has changed a bunch of times, including being on DST for a few years straight in the 70s.
If it’s not already configurable then it had to be replaced in 2007 when we last changed the start of DST.
Well then to be fair you’d have had the same problem if they just changed the start date again. And the last time the start date was changed we only had 18 months to adjust.
It’s not like these changes are rare edge cases — it happens all the time.
So hopefully as you replace the system you find a vendor who writes good time code!
More than these exceptions, gadgets nowadays like to be IoT's and use internet time servers. The blast radius on things made since 2007 is likely smaller than you think.
It depends on what it asks for. If it asks for “current time in PDT” or “current time in PST” it just returns the same answer.
If it asks for UTC and does the conversion locally, then we’re back to the original problem of being able to update the switchover date which changes all the time and should be updateable.
Interesting, you're right. However does that not present a backdoor by setting up a local time server to proxy changes? It's a hack but ... a solution.
What's the difference between "Don't switch times and set the time correctly to the current DST" and "Don't switch times and set the time correctly the current standard time"?
Daylight savings rules change, somewhere around the world, several times a year.
For example, between 2011 and 2016 Istanbul changed their DST rules 7 times [1]. So I think you'll find a great many systems already have a way of distributing DST rule updates.
Sure, I know all about the joy of adjusting tz databases, etc.
There are a whole lot of things here in the US that have basically never required these updates.
And, well, there's all the problems where people have assumed timezones won't change, and e.g. have stored timestamps of future events in UTC in databases that really semantically are supposed to be at 9AM in a given timezone.
We didn't observe daylight savings here in Indiana until about a decade and a half ago, and we have our own time zone in everything still (go look, you'll find "Indiana (East)" or some such). I can't imagine it'd be too difficult to implement.
This might also affect northern non-tech businesses like ski resorts. They’ll either have to open an hour later (and possibly stay open an hour later), or install lighting.
It might also affect things like outdoor after-school activities that will now have enough light to be held during winter, which in Northern California potentially means extending or shifting the soccer season.
People deal with a random shift of light twice a year now, they cannot deal with no change? It's not like these decisions all need central planning and we must cover every edge case: people figure out what to do in a distributed way.
It's more complicated than that. Everything that calculates differences between two points in time for example would need to be updated to know about when the switch occurred. And more generally, this is an example of why it's complicated - because it's easy to overlook things that could be affected, so there's a great deal of investigation and testing that would need to be done.
Many systems that are in production have no regular release schedule, may go decades without any changes to code, and they have no maintainers.
The delay is for those cases -- where someone may need to be hired to fix it, or an entire system may need to be replaced if it is no longer maintainable.
Sure the actual change might not sound super complicated, but hunting down all the little machines, services, and ancient code isn't easy for all organizations.
Most people don't that though. They use databases, system and apps that implement their own logic for time changes. Maybe you need an OS update. Maybe it's code that is controlled by a third party. There's plenty of logistics necessary to make sure things don't break when the DST rules change.
Yeah that's not gonna happen until October 2024. See GDPR as an example.
The regulations were adopted in April 2016, but they didn't become enforceable until May 2018. Most companies didn't even start thinking about it until March 2018 or later. The first fine was handed out in May 2019.
if it took effect too quickly, you would frequently find yourself second guessing that computerized system telling you when to be somewhere. "Oh that's right, Delta airlines hasn't switched yet but Southwest and Lufthansa have. Oh well, I'll catch the next flight."
Just think of all the phones whose software updates have recently expired. No one catches on right away that their security updates stopped rolling in. But they'll definitely notice when their phone stops matching the time that they talk about on the radio.
A few years' delay would be comparable to the DST changes made in 2005 (which went into effect in 2007 -- they extended DST in the US by a month on each end; moving it from Apr-Oct to Mar-Nov).
Dunning–Kruger effect is very real. There so many systems affected by this on all kinds of timelines and life support that such a change would be catastrophic. Just because it may seem simple to you doesn’t mean it actually is.
Other countries have made these changes on shorter time frames in recent memory. I don't recall hearing about any catastrophes.
In 2011, Samoa changed time zones to land on the other side of the international date line. I don't believe that was years in the making. Even last year, they announced they would no longer observe daylight saving time; they decided that 11 days before they were scheduled to switch their clocks.
In January of 2015, Chile announced they would keep daylight saving time year-round when they rolled forward in April. Then in 2016, they scrapped that. In 2019, they even changed the dates on which daylight saving started and ended. While this was over the course of several years, they didn't go into this thinking about how to make it complicated for the next four years.
Many of the states don't seem to think this is a serious concern, either. Several, including my own (Kentucky) passed legislation to permanently observe daylight saving as soon as Congress would allow it. I don't think the folks considering these measures are underestimating our ability to deal with these types of changes.
The late changes to daylight saving time rules pretty much always mean that for several days to potentially over a month, users will be encountering systems with the incorrect time. Often times they will try to "correct it" by manually changing the system time but then time sync services might undo that, and if not, then once the time zone package finally makes it to the system, it "breaks" again, because the user should not have messed with the clocks in the first place.
The authors of the time zone database strongly encourage long notice periods for changes, as there are plenty of programs that use this data that have a month or more of delay between when an updated database is published, and when end devices will realistically get the update. And that is for people who don't habitually put off updates!
When DST rules were last change we had about a year and a half notice, which is realistically what this bill also provides.
I understand that there are a lot of systems that will be impacted but I don't think we should limit progress based on dependencies. It's the same excuse that's used whenever we try to ween off of fossil fuels.
I've worked on tzdata changes in the past and whether it's announced a month or a year in advance, progress is slow until the very last minute when teams can't put it off any longer. In other words, programmers are serial procrastinators and if you give them 2 years to prepare, they'll spend 1.9 doing nothing and scramble to fix everything in a month.
This might be the first big timestamp change in the US, but there have been a lot of changes like this in the rest of the world so any globally operating company has probably had to do this at least once already and should be well equipped to make this change on a faster timeline.
This is not even what the common wrong Dunning-Kruger interpretation means, even if we don't consider that the whole thing seems to mostly be a statistical artefact.
> The Hill article[1] says it won't go into effect until November 20, 2023.
Way too soon. Stupidly so IMHO.
I went through the last DST law change, and it took quite a lot of work in many IT areas. Unixes weren't too bad, but there was all the JREs, databases, etc.
And that's not getting into all the embedded and industrial gadgets.
Repeat after me, "job security". I just hope we still have some 32-bit machines running in 2038 so that after I've conveniently retired, I can be called back in to consult.
I'd be curious to know, to what extent did that change prepare the world for this change? Was it more common to adapt IT systems to be more flexible, or to do minimal work to change hard-coded values? I imagine it was a mix but the pessimist in me thinks overwhelmingly the latter.
Yes, there were a lot of changes, especially given the concentration of software development in the US.
At the time I was dealing with Solaris a lot, and previously you had to reboot the system for things to become permanent, but there was a tweak made where the system started to stat() the file /etc/localtime to see if it changed, and reload it if it did. So new process would get the new tzdata bits.
Previous the US tzdata bits hadn't change in several decades, over the course of the 1980s and 1990s, when basically the entire computer industry mainstreamed. So things may not be as bad as last time—but I'd still prefer a little extra time.
> One reboot during a seven month window doesn't sound too bad either.
It is on 24/7 systems that had no budget for HA, especially if you had several hundred/thousand systems and things like Ansible and Chef weren't invented yet. CFEngine was the big boy in town and Puppet was an up-and-comer. (Remember this was the 2000s).
> The National Association of Convenience Stores opposes the change, telling Congress this month "we should not have kids going to school in the dark."
Wouldn’t it be more “convenient” to have children go to school at a time that is in line with their natural sleep patterns? From the CDC [1]:
“The American Academy of Pediatrics has recommended that middle and high schools start at 8:30 a.m. or later to give students the opportunity to get the amount of sleep they need, but most American adolescents start school too early.”
Agreed, but my point is that under this new law, schools will be effectively starting at 6:30 (as we've been measuring time in the winter). This means we're bringing school start times in the wrong direction and will have to move them forward by 2 hours rather than 1 to get to a reasonable start time.
This is mostly high schools. School buses take two or three rounds in delivering kids to school, starting with high schoolers, then middle schoolers, then elementary schoolers. There is all sorts of variation to be had. Middle schoolers in my neighborhood seem to start school at 9AM or at least after 8:30.
Unfortunately, that is NOT what the article states. DST (Daylight savings time) ENDS on November 5th (when we change back to what is called "Standard Time"). 2 weeks later, DST (not ST) becomes the law of the land. Which means, as the OP stated, unless they change the implementation date, there will indeed be a 2 week flip-flop.
Even more important note from that article: "The House of Representatives, which has held a committee hearing on the matter, still must pass the bill"
I don't think there's any guarantee that they will even take up the bill, much less vote for it. (Hopefully, I'm wrong, because I would love permanent DST)
There's never a guarantee but being a unanimous vote in the Senate and one of the few bipartisan things that can actually pass both houses, I'd say it's pretty likely it will pass in some manner.
Presumably your state chose to elect some of the senators who voted unanimously to pass the bill because the electorate trusted their judgement. Sometimes making the best judgement that means consulting with interest groups like airlines, who offer an important service millions of Americans depend on. I'm not sure what you're unhappy about here
That requires Restrictions on free speech, which would be difficult to do (1A).
New Zealand has political campaign budgets, and limits on airtime. However restricting private citizens is difficult.
There was a significant controversy in the 2005 New Zealand elections regarding budgets. It is alleged US fundamentalists significantly (for NZ lol) funded the Exclusive Brethren Church to produce pamphlets in support of the National Party, by smearing both the Labour Party and the Green Party. https://en.wikipedia.org/wiki/2005_New_Zealand_election_fund...
Pollings actually shows legislators are exactly in lockstep with voters. For instance, a strong majority of Americans say they would not pay an additional $10 per month in electricity to combat climate change. So legislators faithfully do nothing to combat climate change that would cost voters in any way. You may not like it, and neither do I, but the problem is with the voters rather than the politicians
I went to the ballot and saw someone running for Senator who I had never heard of, against other people who I had never heard of
And the other Senator ran unopposed for a party different from my Presidential ticket pick, but not like that matters because my state is too populated for my vote to have the same weight, or any weight, in the outcome
If you've never heard of your states senators, that's pretty sad. I knew who my state's senators were when I was like 6, or at least the senator for my district.
There's only two of them, you can definitely learn about them.
This does not make the rest of your comment untrue.
I knew at least one of them at least one at one point in time, and I didn't even live in that state then. I would say its pretty sad you're in the same place you were since you were 6.
I guess the point is that we don't know anything about each other and can't make any conclusion really, except that states don't choose anything with any coherent rationale because the individuals are on just as wide of a spectrum of awareness and lack of choice.
For context, BC, Washington, Oregon, and California have all passed state bills to move to permanent DST but need Federal approval per U.S. law. In short, they did get approval from the time zone who will be first to make the change, and the support is pretty overwhelmingly in favor. The North American west coast will change as one to full time DST if this passes the House and is signed by the President.
From some of the industries that would be most impacted by it, and those impacts being ones that would cascade to the people who fly or consume broadcasted media?
Important note: "Senator Marco Rubio said after input from airlines and broadcasters that supporters agreed that the change would not take place until November 2023."