4 ms·
Another faction would be the developers that have to deal with the time changing. Would just be easier to change at a personal level than changing time itself.
by drawkbox 5y ago
Another faction would be the developers that have to deal with the time changing. Would just be easier to change at a personal level than changing time itself. Arizona doesn't do alot right but no DST is one big one they do. Times of work/events/appts/etc change, not time itself.
- zaat 5y agoI think you misspelled sysadmins there. My experience is that, at least in the traditional corporate world, it is the DBAs who connect just before midnight to put their precious SQL servers to sleep during the danger time, since who know how the software will behave in the real world. In some places DST dates are often changed in the last minute, wrecking havoc everyone's calendar meetings and inflicting pain on the Exchange servers admins.
- eru 5y agoThat seems a bit silly to me? That's a problem that occurs every years twice; so we should write code to automate it instead of dealing with it by admin hands.
- RajT88 5y agoThe problem is we have to keep updating that code when the rules change. Servers which miss that patch break because of various Auth schemes which require clocks to be reasonably in sync between machines. So you get a bunch of outages whenever the next time shift is post-rules change. I am less annoyed with DST than I am at how often we are fucking with it and breaking stuff.
- fphhotchips 5y agoI like it when the US fucks with time zones. The more you fuck with time zones, the more likely US-based developers are to just say fuck it, we'll use a library. The more developers that use a library for time zones, the fewer pieces of software that I have to deal with that get this wrong for my part of the world. (Did you know Australia has 11 possible time zones of which up to 9 are being used right now? It might even be 12. Most people don't, which is why most programmers fuck it up)
- eru 5y ago> The problem is we have to keep updating that code when the rules change. Yes, indeed. But we also have to change what people do manually when the rules change.
- smegger001 5y agoremember this is a industry that thinks run fast a break things is a good motto. is it any wonder that the same people that need reminding that name fields should accept non latin character and that passwords should in fact be more than 8 characters would consistently fuck up something that only comes up twice a year.
- eru 5y agoI used to work with a system that 'conveniently' silently dropped leading and trailing space in its password field (and also just copied the password into an https-URL without any encoding, so no special characters for you). The guys who committed this crime thought that only weirdos like me have such strange passwords..
- hannasanarion 5y agoThere were 7 time zone changes in the world last year, and nobody's systems collapsed, most of us probably didn't even know they happened. That's because every developer and sysadmin with more than a year of professional experience knows that you never, ever, do your own time zone math. You use your system time utils, and keep them updated so that your code reflects the latest laws.
- drawkbox 5y agoOf course, I hope people aren't implementing time zone utils on their own unless absolutely necessary. Though, there are devs that work on those system tools. There are also cases where times need to sync and the changing can cause some issues. Stored times should be UTC but where they aren't it can makes some systems use local time incorrectly for a bit on the rollback. I have also seen network libs in games not use ticks for session starts that would be problematic on rollbacks playing at switchover. There have also been flaws in system time utils previously. Lots of unnecessary potential edge cases, all for an unnecessary time change of time itself except a few places like Arizona.