4 ms·

The real problem with the time change is it happens over a single night. When you're actually living in nature, waking up with the sunrise, you will gradually

• recursive 8y ago
  Under this system, either some minutes will be longer than others, or we'll have leap minutes every night. This sounds more complicated, not less. It might achieve the goal of having a sunrise at the same wall clock time every day, but I don't really see a purpose for that. Sunsets will still vary.
  • newnewpdro 8y ago
    I made no claim of it being less complicated, and I am not aware of the general public's primary issue with the time changing being one of complexity. If the clocks are automated, nobody really notices the gradual change. My perception is the public's major complaint is the jarring disturbance to their lives an overnight +-1-hour change has.
    • recursive 8y ago
      As a person who works on software that cares about what time it is, and already struggles with the existing DST rules, I think I would change careers if this were adopted. Measuring the elapsed time between two instants would become extremely difficult.
      • newnewpdro 8y ago
        We're already in a world where you really need to rely on external date+time libraries to apply a locale-specific temporally-varying offset from UTC. I don't see it as being a significant implementation difference if that offset changes a smaller amount at midnight on a short sequence of days vs. a larger amount at midnight on just one of those days. Either way you need to be leap-aware.
        • recursive 8y ago
          The amount of information embedded in leap-awareness would be significantly different. Right now DST is modelled as two different time zones that are switched between. If you want to handle it the same way, I guess you'd need 365 (366?) "time zones" per time zone. I can't see how you can argue that's not a significant implementation difference.
          • newnewpdro 8y ago
            Let's say we wanted to turn it into a gradient where we instead shifted five minutes per night, so we need 12 days to transition an hour. You could just add a transition countdown field "-" to the "S" and "D" timezones being transitioned to, dropping it once the transition is finished. e.g. for Pacific time: PST -> PD-12T -> PD-11T -> PD-10T ... PD-1T -> PDT and in reverse: PDT -> PS-12T -> PS-11T -> PS-10T ... PS-1T -> PST If you already have the indirection of the table, it doesn't increase implementation complexity to put some more rows in it. I don't see where you got 365 zones per time zone, unless you thought I was proposing we change the time a little bit every single day of the year. That's entirely unnecessary to eliminate the practical nuisance of the sudden 1-hour jump.
• colejohnson66 8y ago
  The problem with gradual shifts is that physical clocks are pretty dumb and changing the clock once every 6 months is easier than 4+ changes over the course of a month.
• madcaptenor 8y ago
  William Willett, who was a promoter of DST in Britain, proposed advancing the clock by twenty minutes on four Sundays in April and taking it back twenty minutes on four Sundays in September (http://www.webexhibits.org/daylightsaving/willett.html http://www.webexhibits.org/daylightsaving/willett.html), sort of a compromise between continuous adjustment and the one-shot that we have now.
  • mark-r 8y ago
    I hope you mean either three Sundays or 15 minutes, otherwise you don't get an hour. It's enough of a pain to change all the clocks twice a year, I'd hate to have to do it 8 times.
    • madcaptenor 8y ago
      No, four Sundays and twenty minutes. I was surprised too.