Hacker News Reader

Comment by mdturnerphys | Hacker News Reader

More info here: https://www.reuters.com/world/us/us-senate-approves-bill-tha...

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."

View on HN

The Hill article[1] says it won't go into effect until November 20, 2023.

> The proposal would not take effect until Nov. 20, 2023, to give airlines and other transportation industries more time to adjust to the change.

But we switch back to standard time on November 5, 2023. Just to get two weeks of that until we switch back to summer time permanently?

[1] https://thehill.com/homenews/senate/598314-senate-unanimousl...

This made me laugh out loud.

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.

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.

Think of all the code that needs changed. I can wait another year or two, just as long as we actually commit and follow through.

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.

If you're a SaaS app, sure. You can't easily "npm update" an airplane, though.

Like, if nothing else, think about all the plane tickets already sold for an hour that doesn't exist anymore.

Airplanes receive software updates all the time.

Hopefully not via npm

You don't even want to see the node_modules folder on a Boeing 787.

What about all the embedded systems out there, which do very important things with timekeeping?

What about all the existing appointments, etc.

IMO 2024 -- 2 years-- is just the perfect amount of time. It's slightly aggressive but doable.

If people frequently make appointments, buy tickets, etc, for a year out, that leaves a year to get most of the software world cut over.

> 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.

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.

> If it’s not already configurable

It's not.

> If it’s not already configurable then it had to be replaced in 2007 when we last changed the start of DST.

Yup, both these systems are about 10-15 years old.

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.

Using internet time servers is largely the problem, because then you need to take UTC and make it into a useful local zone.

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.

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.

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.

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"?

The choice is often one of 4 named timezones for NA (with hardcoded offsets to UTC) and "Automatically Do Daylight Savings Time" on or off.

So, the workaround is probably setting a lot of things to the "wrong" timezone one zone east, with daylight savings time off.

In turn, the logs will be lies, etc.

"Always in Daylight savings time" is just a different time zone. Doesn't need a setting of its own.

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.

[1] https://github.com/eggert/tz/blob/main/europe#L4014

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.

> IMO 2024 -- 2 years-- is just the perfect amount of time. It's slightly aggressive but doable.

Yes, perfect, most developers start working on this Q1 or Q2 2024 at the earliest.

>What about all the embedded systems out there,

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.

A lot of systems only do major updates every two years. I guess you could push DST as a security update.

Are you serious? The code would be to simply not change time zones 2 times a year. Sure needs testing but should be an elegant simple change.

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.

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.

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.

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.

That's badly written code. Timezones (globally) changed over time. Even Bush Jr. changed DST.

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.

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.

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).

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.

Hah, thanks for pointing that out. The articles on it really should say when permanent daylight time would start, not when the bill would take effect.

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.

https://codeofmatt.com/on-the-timing-of-time-zone-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.

https://arelbundock.com/posts/dunning_kruger/

That also means existing software/firmware will continue to use correct TZ offsets until November 2024, so that's the deadline for updates.

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.

The bill doesn't appear to have an effective date: https://www.congress.gov/bill/117th-congress/senate-bill/623...

There was an amendment adopted to set the effective date to Nov 2023, it just doesn’t display on Congress’ website (yet).

> 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.

No thanks. My job security is being competent. The less drama I have the better I'm doing my job.

Know anyone who ended up rich thanks to Y2K? Possibly not since chances are they went into early retirement.

> I went through the last DST law change

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.

The JRE/JDK has a separate tzdata updater:

* https://www.oracle.com/java/technologies/javase/tzupdater-re...

So it may not as bad as it was in the past.

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.

Thanks for this answer.

> Solaris

Haha, I worked at Sun at the time and definitely remember some of my coworkers grumbling about it.

One reboot during a seven month window doesn't sound too bad either.

> 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).

* https://en.wikipedia.org/wiki/Infrastructure_as_code

The last DST change gave about a year and a half notice. This also gives a year and a half notice.

But that is a super, super weird date given that it means we would set the clocks back, and then set them forward again about 2 weeks later.

> 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.”

[1]: https://www.cdc.gov/sleep/features/schools-start-too-early.h...

This makes the problem worse. If 8:30 standard time is when school ought to be starting, that's now 9:30, which is even less likely to happen.

8:30 is when schools ought to be starting, which will be after sunrise for every state in the union, except Alaska, even on the darkest day.

Most schools in America currently start at 7:30, which is way 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.

>Most schools in America currently start at 7:30,

I guess I learn something new every day. So Breakfast at 6? Leave home at 6:30?

I imagine this is because this give enough time for parents to go to work after they dropped their kids?

Thank God we have boarding school in the UK.

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.

>School buses take two or three rounds in delivering kids to school, starting with high schoolers, then middle schoolers, then elementary schoolers.

Oh this makes perfect sense. Thank You.

You could really think of it starting in March 2023.

~~I assume they'll be doing the November switch and staying on it permanently. So, it wouldn't be starting in March 2023.~~

Seems like I misread what was stated in the article.

> They will *not* make the November switch...

Ftfy

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.

There is no "implementation date" in the current text of the bill. As written, it would take effect immediately.

I suspect it is in the amendment[1], which does not yet appear to be on Congress' website, as it was just passed earlier today.

[1] https://youtu.be/_WS64Q3-emk?t=37

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.

That’s pretty soon. It makes sense to take some time to prep.

They're handling it better than Samoa did, anyway [1].

[1]: https://mm.icann.org/pipermail/tz/2021-September/030397.html

I see what you did there.

I wonder how many bugs will pop out because of this. Time is already pretty complex… and it might force some old systems to need updates.

Reply on news.ycombinator.com