13 ms·
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.
by bootlooped 5y ago
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.
- parineum 5y agoIf 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.
- gkoberger 5y agoIf 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.
- mlyle 5y agoWhat 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.
- munch117 5y ago> 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.
- mlyle 5y ago> 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.
- jedberg 5y agoThe 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).
- mlyle 5y ago> 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.
- ars 5y agoA lot of systems only do major updates every two years. I guess you could push DST as a security update.
- r00fus 5y agoAre 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.
- gen3 5y agoSure 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.
- tempestn 5y agoIt'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.
- dudus 5y agoMost 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.
- kube-system 5y agoMany 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.
- pishpash 5y agoThat's badly written code. Timezones (globally) changed over time. Even Bush Jr. changed DST.
- awb 5y agoThis 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.
- pishpash 5y agoPeople 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.
- fy20 5y agoYeah 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.