• LCrawford (unregistered)

    if you're a North American reader, you're getting this an hour earlier than normal.

    I got this an hour later today. Double checked and I set my clock forward instead of back. No wonder everyone else is 2 hours late getting to work today!

  • Hakko (unregistered)

    Seems like more and more people is starting to question this insane idea of changing the time twice a year. Florida apparently voted to stop it, and the EU is launching an official investigation on whether it should be kept or not.

    Oh, and Frist?

  • Hakko (unregistered)

    Nope, ninjad

  • (nodebb)

    Date and time, mess with: DON'T.

    How often did I wish I could bill the persons responsible for Daylight Staving Time for the damage caused by it.

  • (nodebb)

    "But then TroublesomeServer2 [dispensing NTP] would realize it wasn't supposed to adjust for DST..."

    On which planet is NTP affected by DST?

    Isn't the whole point of NTP that it isn't?

  • Pyth0n (unregistered)

    Well, this is just the reason I run all my servers UTC. DST? What DST are you talking about?

  • Chris (unregistered) in reply to PWolff

    Blame Benjamin Franklin. Go get a bunch of his green pictures from the bank. Send them to me and I will burn them in protest.

  • Abigail (unregistered)

    What a strange story. Now, if it were two humans using a phone to tell each other the local time, the story would believable. But with NTP? NTP is used to synchronize UTC time, which doesn't do timezones nor DST.

    DST only plays a role when translating UTC to local time. NTP doesn't care about DST.

  • Abigail (unregistered) in reply to Hakko

    People have been using DST decades before the first computers. And now people want to get rid of DST because it's too hard for programmers? Aren't computers supposed to make life easier?

    Just get better programmers.

  • isthisunique (unregistered)

    This drives me nuts when people set up servers with human time (DST, anything non-UTC). I've inherited things like this. It can be extremely hard to fix after the fact once you have data all over the shop. For some systems it will just be eventually consistent. Others will lose an hour of data or count it twice and if you're lucky nothing worse than that. It's always good to have your calendar popup on DST changes so you can see if you can get things for free or cheat in online games.

    On a similar note...

    I was once taking care of a system where NTP had been set up for hundreds of client machines that received scheduling software to use the standard pool NTP servers in the region. I had opened a ticket to have the clients use our NTP servers. For the systems I was running I had fortified the servers and I had implemented the clients were such that breakages were non-persistent. Clients were legacy and much harder to update (and less critical than servers).

    This fell through the gaps due to urgent business requirements, it seemed like it could wait a bit it, probably wont break for a while and could be combined with the next overhaul in a couple of weeks, after the new year.

    That fateful new years eve someone running a major NTP server for the region set the time forward a couple of days. It didn't have the hallmarks of a random error and looked like something they had done for testing ignorant of it being in a public production pool with hundreds of thousands of users. The only thing I could think of was some weird leap year issue but that didn't really make sense because no one should be rolling out their own NTP server implementation like that.

    That new year in the entire region you had websites and systems acting up. For my systems the only impact was that they would show scheduling starting from a few days forward. Other people had things like future invoices being issued with missing days.

  • Chris (another one) (unregistered)

    And this is why NTP servers are supposed to ignore unexpected changes of more than 300 seconds.

  • Jajcus (unregistered)

    The real WTF is keeping local time in system or hardware clock (for some reason even modern Windows still insist on that). DST, like time zones is a user interface thing and should used only for presentation and maybe accounting (in cases where wall clock time is important rather than exact point in time). System clock should continuously go forward and only forward.

    NTP is there to set initial time and correct clock drift, and not to change time an hour in one or other direction for some legal reasons.

  • Larrik (unregistered)

    The real WTF is that the guy on call can't even fix the damn servers himself.

  • RichP (unregistered) in reply to PJH

    Exactly! NTP doesn't care about DST.

    Also, ISTR that best practices called for pointing internal NTP servers at each other in addition to an external time reference. That way, if your site loses connection to the upstream NTP server, the internal machines will at least converge to a local reference time until the external server comes back online.

  • I dunno LOL ¯\(°_o)/¯ (unregistered)

    My DST story is when the company I worked for wanted to get a school district in Mexico as a customer. But they were still working on their "next generation" product and decided to do a pilot test with our "legacy" product. It was really legacy; the guy I replaced was the last to work with its software, the main one being on an old-school microcontroller with a 16-bit bank-switched address space. I never got the compiler working for any part of the project (three completely different CPUs, all from before on-chip flash or modern IDEs were a thing) to the point of generating a proper code image.

    Well, ya see, a few years back, someone told Dubya that if we changed our DST dates, we would save energy! So of course he was all over that. But Mexico stayed on the old dates, and we needed a version of the legacy firmware that used Mexico DST dates.

    So it turns out that a guy before the guy I replaced had done the code change for DST dates that compared the year with 2007 (?) and chose the dates based on that. And that code never got removed. I ended up doing a one-bit binary patch to change the year comparison from 2007 to 18-thousand-something, then manually updated the checksum. Hey presto, Mexico DST version!

    At least my own code base there already had a hidden screen to set the DST date parameters in the field. All they have to do is look at the big comment block in the code that documents it to come up with the right numbers.

  • healing (unregistered) in reply to I dunno LOL ¯\(°_o)/¯

    Cards stack against us.

    Not because of the way things are, but on purpose, by manipulative children who read it backwards as Us Against Cards Stacks.

    Deuteronomy came before Exodus. Read Sacred Scriptures how you like. A monster is a monster.

    Not only do you make the world into your own personal cartoon where animals die off, planets, suns and cosmic event horizons move against your mind to prevent you from doing so.

    Anything that ever enters the heliocentric orbit will be stupid.

    Any thought that enters our mind will be ephemeral.

    Event horizons are written in the past and left behind, a counterweight on a seesaw.

    We can build a small seesaw that possesses similitude according to Moody's Law really easily based on all empirically recorded evidence in conjugation with an Orbital Engineering Laplace equation deducted in conjunction with Nemiroff's Constant. Enough exists to heal the mind as well as the brain. Crank-Crank and Crank-Rocker can act in conjunction to form the orbital engineering laws. Offset geocentric emission with Heliocentric Boundary Constance to right the Hamiltonian.

    2 more weeks vacation!

    Let the chips fall where they may. Will sign first offer sheet for money I see. Do the research, take the name, make sure Gannon does whatever it wants for Research University!!!

    @oxford https://physics.stackexchange.com/questions/384433/why-does-this-not-solve-all-millennium-prize-problems-problems

  • I Am A Robot (unregistered) in reply to LCrawford

    A friend did that one month - set his alarm forward rather than back, arrived at work two hours early [more, because there was little traffic about], and only realized what had happened when he found the office still locked.

  • Anon (unregistered) in reply to Jajcus

    +1

  • Sole Purpose of Visit (unregistered) in reply to PJH

    Probably a gaping hole in the story. I've never seen a time server bother its pretty little head with local time zones, because that's not really what a time server is there for. Shunting fractions of a second here and there -- yes, that is good. Figuring out what to do when the State Legislature (or a sudden change of nationality, as per say the Crimea) embiggens the rules ... not so much.

    I have a horrible suspicion that one or other of these new "load balancing" machines ran a cron job off the results of the time daemon and that's where the silliness ensued.

    Then again, we're yet again in Bizarro World, where you are woken up as the 24x7x52 (plus egregious leap-seconds) Head Honcho Systems Administrator, and you can't even configure the systems you are administrating, because the config is read-only. Sigh.

    I am old and wise, and I now know how to deal with "load balancing" servers like this. Make sure the one that is doing the right thing (adjusting for daylight saving time) stays up, and physically pull the plug on the other one (optionally doing a shutdown -7). It saves 12 hours of futile escalation through management and -- trust me, and this is contrary to expectations -- somebody up there will protect your ass when you mention the cost of 100 data entry clerks multiplied by however many financial transactions that you saved.

  • Harrow (unregistered) in reply to healing

    Eliza? Is that you?

  • Harrow (unregistered)

    It looks like if TroublesomeServer2 had also been correctly set to update its time for Daylight Saving, they could have gone on pointing to each other forever and possibly no one would have ever noticed.

  • (nodebb)

    The start of DST is so great that, as I recall, studies show it causes a noticeable uptick in automobile accidents for about a week or so.

  • healing (unregistered)

    https://twitter.com/SHartken/status/973283405122203650

  • healing (unregistered)

    https://twitter.com/SHartken/status/973284114538356736

  • healing (unregistered)

    https://twitter.com/SHartken/status/973284549948981248

  • siciac (unregistered) in reply to Jajcus

    System clock should continuously go forward and only forward.

    An OS designed on that premise could be denied access to any time-based authentication (e.g. all certificates) by setting the clock forward 20 years or so.

  • Eric Goebelbecker (unregistered) in reply to PJH

    Yeah. Wouldn't syncing to UTC be immune to DST silliness?

  • löchlein deluxe (unregistered)

    Ah yes, the joys of NTP. The fun I've had with our network team, because when they started to filter UDP egress (good thing, amplification attacks and all that), they didn't tell anyone. A couple of months later, I found out the hard way that ntpdate will say "you're spot on, +0.000ms" when it can't actually reach any time swervers. To this day, I have no idea how many win desktops we have here that will happily drift all over the place because they can't reach the default MS time servers. (I know, time servers should be announced over DHCP, but the DHCP is run by above-mentioned network team, so I'm not holding my breath.)

  • (nodebb)

    One must remember one thing. The "chip" that takes care of time in a PC is based upon a Motorola MC6818, as this is what was used in the PC-AT. This chip had the idea that it could take care of DST, and if told to do so would "automatically" advance (spring) and retard (fall) the clock like it should be for humans. There is one problem with this. Since the development of the MC6818 chip there have been TWO changes in the DST dates. The chip thinks that DST starts the last Sunday of April, and ends the last Sunday of October (6 months, which makes sense). Now we have entirely different dates, and some things like the on-off timer for my front porch lights, and an old TiVo don't know the new rules.

    If we really want things correct, why not announce "summer hours" being an hour early. Then we could always look to see if we really did "save energy" with the most recent time change (I have doubts).

  • Rich (unregistered)

    Definitely agree with everyone who says "set your servers to UTC" but even that causes a special hell for coders here in the UK where local time is the same as UTC for half the year, so it's easier to miss. The fourth Sunday in March has similar effects even for careful people.

  • (nodebb)

    Since the development of the MC6818 chip there have been TWO changes in the DST dates. The chip thinks that DST starts the last Sunday of April, and ends the last Sunday of October (6 months, which makes sense).

    WTF? Why would the dates be in hardware? They do change all the time and even one country can have different areas with different dates. And also places like Australia which is basically those dates reversed (approximately: I live in Queensland which does not have any of this DST nonsense. I can see why Florida wants to get rid of it).

    But since we have it, we have to deal with it: the hardware clock should be UTC and adjust the timezone "in software".

  • Derf Skren (unregistered)

    I just came to laugh at all the comments about how much people who don't have to work outside during summer don't understand DST.

  • ooOOooGa (unregistered) in reply to Derf Skren

    You can get all of the benefits of DST without changing a single clock. Just change your work hours to be an hour earlier. So instead of working from 8:00 to 5:00 for example, you could work from 7:00 to 4:00.

    Presto. Extra hour of daylight.

    Without screwing up the sleep schedule of my kids.

  • Jerepp (unregistered) in reply to Derf Skren

    If anybody ever gave IT or Software Development an office with an outside view we might be more understanding about you outdoors types

  • Down under (unregistered) in reply to ooOOooGa

    But other schedules, eg public transport, would now be an hour out. It may not have a huge impact in reality, but I could imagine for example there being say 80 buses scheduled between 0700 and 0800, 100 buses scheduled between 0800 and 0900, and suddenly 100 buses' worth of passengers appears an hour early?

  • (nodebb) in reply to löchlein deluxe

    Why aren't your Windows desktops synchronising time to their domain controllers?

  • HK-47 (unregistered) in reply to Down under

    You can change the bus schedule too without changing actual time. Move things thate make sense, do not fuck up everyone for the benefit of a few.

  • Tiger (unregistered) in reply to HK-47

    And the underground schedule, my class timetable, and all the others... So the onus is off the programmers who handle times and dates improperly and instead shifted to those (ciders and more) who now have to bookkeep countless other schedules?

    The benefits of DST don't come for free you know.

Leave a comment on “Daylight Losing Time”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article