Daylight saving time



  • Phones get their time from the sync signal on the nearest cell tower. I don't see how or why Windows Phone would override that, since they (the phones) need the synced time to communicate with the towers anyway.



  • @accalia said:

    EDIT: i know i misspelled the name of the OS. I'm not fixing it

    :pout:


  • FoxDev

    indeed not, but it is 10 periods of 24 hours.

    not that many people differentiate between the two even when they routinely have days that are longer or shorter than that (sometimes by as much as 12 hours for transatlantic and transpacific flights.)


  • FoxDev

    :-p


  • Discourse touched me in a no-no place

    @blakeyrat said:

    1) Don't start a post with "um", it's almost as bad as "um, actually". (It's 50% as bad.)

    Um, actually it's only about 20% as bad, based on letter count, not counting other symbols.



  • @Severity_One said:

    You really don't get a lot of sunlight during the winter months. It also means that more children get hurt/killed in traffic on their way to school, which in Europe often happens by bicycle. So that makes the case for winter time.

    No; it makes the case for changing the start/end time of the school day during the winter.

    Daylight Saving Time is applying a global "solution" (if you even consider is a solution) to a smaller problem. Minimize scope. This board's full of programmers, that should be an obvious WTF.



  • Embedded systems. With obsolete OSs that haven't been updated since the law about when DST starts/ends was changed. Clock wrong. If fix clock, will be wrong again next week when the time does change.



  • @Yamikuronue said:

    I think the test looks like

    1. Generate a failure (or series of failures?) with timestamp [currtime - 240 hours]
    2. Verify that the job is cancelled

    But 240 hours != 10 days.

    Exactly. I took 240 hours and five minutes, so you're just before the cut-off timestamp - provided you're not dealing with daylight saving time.

    I've created a couple of standard timestamps for testing, including 'now', 'justNow' (five minutes ago), 'yesterday' (24 hours ago), 'nextMonth' (30 days from now), and 'whenPigsFly' (five years from now, because Oracle gets funny if you use dates later than 2031).



  • Example of how things work at my company: we get a ticket bi-annually to update a bit field to represent whether or not it is currently DST.


  • Discourse touched me in a no-no place

    @chubertdev said:

    Example of how things work at my company: we get a ticket bi-annually to update a bit field to represent whether or not it is currently DST.

    You should be proactive and write a script that updates the field for the next several years and set it up as a scheduled task.



  • @FrostCat said:

    You should be proactive and write a script that updates the field for the next several years and set it up as a scheduled task.

    I am neither a DBA, nor anyone who wants to get called in to explain why I made an unregulated change in production.



  • @FrostCat said:

    You should be proactive and write a script that updates the field for the next several years and set it up as a scheduled task.

    This is assuming that the timezone and DST info are stable. See the mailing list at http://www.iana.org/time-zones for examples of how much fun it is trying to keep track of this stuff. Recent highlights include "What time is it in Crimea / Eastern Ukraine?" and "Will Fiji do DST this year or won't they?".


  • Discourse touched me in a no-no place

    @chubertdev said:

    FrostCat:

    You should be proactive and write a script that updates the field for the next several years and set it up as a scheduled task.

    I am neither a DBA, nor anyone who wants to get called in to explain why I made an unregulated change in production.

    Well, obviously you should get it approved first. Seems like the kind of pseudo-reasonable change request that wouldn't automatically get shot down in a meeting.

    BTW, @codinghorror, it sure would be nice if your software could handle multiple levels of indenting automatically like usenet could in the 1980s.


  • Discourse touched me in a no-no place

    @smallshellscript said:

    This is assuming that the timezone and DST info are stable.

    Oh, no, I wasn't assuming that at all.



  • @FrostCat said:

    Well, obviously you should get it approved first. Seems like the kind of pseudo-reasonable change request that wouldn't automatically get shot down in a meeting.

    BTW, @codinghorror, it sure would be nice if your software could handle multiple levels of indenting automatically like usenet could in the 1980s.

    I've already requested it, the request was rejected.



  • @FrostCat said:

    BTW, @codinghorror, it sure would be nice if your software could handle multiple levels of indenting automatically like usenet could in the 1980s.

    Recall what he had to say about Usenet previously when you pointed out he probably wasn't a huge fan.

    @FrostCat said:

    @Codinghorror probably never handled Usenet well.

    @codinghorror said:

    Neither did normal human beings.

    As if there were ever any normal human being on Usenet.


  • Discourse touched me in a no-no place

    @smallshellscript said:

    Recall what he had to say about Usenet previously when you pointed out he probably wasn't a huge fan.

    Yes, I know. That doesn't impress me, and his answer is also stupid and wrong.



  • @smallshellscript said:

    As if there were ever any normal human being on Usenet.

    I was on Usenet. Make of that what you will. : )



  • @HardwareGeek said:

    Embedded systems. With obsolete OSs that haven't been updated since the law about when DST starts/ends was changed. Clock wrong. If fix clock, will be wrong again next week when the time does change.

    @smallshellscript said:

    This is assuming that the timezone and DST info are stable. See the mailing list at http://www.iana.org/time-zones for examples of how much fun it is trying to keep track of this stuff. Recent highlights include "What time is it in Crimea / Eastern Ukraine?" and "Will Fiji do DST this year or won't they?".

    Yeah. Just wait until you ask the Israelis about DST...



  • @HardwareGeek said:

    Embedded systems. With obsolete OSs that haven't been updated since the law about when DST starts/ends was changed. Clock wrong. If fix clock, will be wrong again next week when the time does change.

    Windows 98 (SE thank Cthulhu) boxes that won't let you change the scheduled time change. System changes time early, operator sees wrong time, changes clock to "correct" time meanwhile DB that is used for scheduling later analysis is now completely screwed since it's reporting the wrong time zone 1 hr off.

    To add insult to injury operators complain that time is wrong in a week when time change happens even though they were the ones who shifted it previously...

    Engineer in charge requests changing all clocks to UTC to eliminate necessity of tracking zones as operators enter runtimes in quantity of hours:minutes:seconds. Management can't wrap their heads around how this would work and say no.



  • @smallshellscript said:

    Management can't wrap their heads around how this would work and say no.

    I take it all that's needed is the appropriately shiny presentation to convince management, eh?



  • @tarunik said:

    I take it all that's needed is the appropriately shiny presentation to convince management, eh?

    Preferably one that includes no math > 2nd grade level.



  • I've used that one too, only to see it spontaneously revert for no reason I could track down (I might well have been TRWTF). It was a while back and all I remember is the subsequent decision not to bother moving Windows out of its comfort zone again. Making Linux use a localtime hwclock instead has never caused me any trouble; in fact the installers for most modern distros will do that by default if they detect an existing Windows partition.

    Assuming all installed systems have up-to-date tzdata, the only scenarios I can think of where a localtime hwclock could actually cause me grief involve physically moving to a new tz between OS shutdown and startup, or having daylight saving start between shutting down Linux and starting Windows (which will then start up timestamping files an hour too late, then step time backwards by an hour as soon as w32time contacts an ntp server).

    Those are kind of rare, but since UTC hwclock would eliminate them altogether it's probably time I revisited making it work.



  • @Severity_One said:

    I've created a couple of standard timestamps for testing, including 'now', 'justNow' (five minutes ago), 'yesterday' (24 hours ago), 'nextMonth' (30 days from now), and 'whenPigsFly' (five years from now, because Oracle gets funny if you use dates later than 2031)

    You should add timeImmemorial for completeness.



  • @flabdablet said:

    You should add <a href="http://www.youtube.com/watch?v=0zHu6XCJF60">timeImmemorial</a> for completeness.

    Good point, although our clientèle from the High Middle Ages is a group somewhat limited in size.



  • I've dual booted for years and I never had any problems between windows and Linux with regards to setting the clock. I just tell the Linux installer to use UTC ... Sorted


  • Discourse touched me in a no-no place

    @smallshellscript said:

    Recent highlights include "What time is it in Crimea / Eastern Ukraine?" and "Will Fiji do DST this year or won't they?".

    Or if you're Samoa, "Which day is it?", and "Will we have a December 30th this year?" (Ok - the latter is hyperbole.)


  • 🚽 Regular

    @anonymous234 said:

    This is a strong enough reason to oppose space colonization IMO.

    Relativistic effects would be the least of the problems, because you just know everyone would want to use their own local version of years and days.


  • ♿ (Parody)

    @HardwareGeek said:

    I was on Usenet. Make of that what you will. : )

    This place kind of reminds me of some of the better places on Usenet. Better places for discussions, obviously. Not better places for binaries.



  • @blakeyrat said:

    Daylight Saving Time is applying a global "solution" (if you even consider is a solution) to a smaller problem. Minimize scope.

    Minimize it? Fuck that. I say we CADT the entire global timekeeping system.

    When I am appointed King of Timekeeping, I shall make simple-minded watches and clocks illegal, and abolish all time zones.

    I'll have the SI second officially renamed as the "sec", a move akin to spelling the metric ton as "tonne", in order to free the traditional second from the straitjacket of being required to describe an accurately consistent time interval.

    GPS time will replace UTC for scientific purposes, and it will be illegal on pain of imprisonment to store any timestamp in a format other than a single signed number (not necessarily an integer) representing secs since GPS epoch.

    For personal, commercial, legal and traditional purposes, GPS-linked standard clocks will convert GPS time to a local second, minute, hour, day, month and year. No time or date specified in these traditional units will have any meaning without an assumed or accompanying set of GPS coordinates.

    Making appointments with people more than a few hundred kilometres away will therefore require the proposed time to be qualified as "your time" or "my time", as is necessary already across time zone boundaries. Given the way human populations concentrate I wouldn't imagine most people will be inconvenienced much by this, while substantial numbers living near present-day time zone boundaries will actually be better off. People living near the International Date Line will remain as confused as ever.

    By default, standard clocks will use their own GPS-provided locations to do the conversion. The only adjustment provided by any standard clock will be an arbitrary choice of assumed location. Public use of clocks requiring other kinds of timing adjustment will invite the kind of opprobrium presently reserved for bestiality and paedophilia.

    The GPS time to local time conversion will be done in such a way as to minimize variation in the duration of seconds while keeping every 86400-second interval as close as possible to 86400 secs, given the constraint that sunrise must always happen at 06:00:00 everywhere. The result: automatic continuous DST with no jetlag-inducing time steps, no time zone politics apart from occasional arguments over the IDL, and no leap seconds.

    The philosophical notion of a "point in time" will be abolished. A timestamp expressed to any given degree of precision will henceforth be taken as referring to the entire interval starting from and including the expressed time, and finishing before but not including the next greater time expressible using the same degree of precision. For example, 11:23am will specify the entire 60-second interval ending before 11:24am. This interpretation will also apply to times expressed in secs since epoch.

    Following from that, "midnight" and "noon" will be taken as strictly synonymous with 00:00:00 and 12:00:00 in 24-hour format, or 12:00:00am and 12:00:00pm in 12-hour format; the former point-in-time definitions for midnight and noon will correspond to the beginning of the one-second intervals for the new interpretations.

    Displaying or storing something purported to be a time in 24-hour format that has an hour component greater than 23 will result in the person responsible spending the interval from 00:00:00 to 23:59:59 (local market square time) locked in the stocks being pelted with rotten cabbages.

    Bug reports invited.



  • If we insist on a DST, we could at least implement it by making the day end at 23:00 or 25:00 once per year, instead of going back to 2am when it's 3am. That way we would still be able to rely on the assumptions that "time only goes forward" and "every timestamp happens exactly once".


  • BINNED

    So implementing the old local time using modern technology? I approve (see user name)!



  • Not quite. The datum for pre-tz times was traditionally solar noon at 12:00:00. My Way New Local Time Paradigm fixes 06:00:00 at sunrise, which causes small seasonal and geographical variations in the duration of the second but means that all variation in day length happens in afternoon and evening hours. This achieves all the advantages of DST without stress to cows and office workers.


  • BINNED

    @flabdablet said:

    The datum for pre-tz times was traditionally noon.

    So 6 am is the fixed point instead of high noon. Big deal.

    But while we're nitpicking, how would this work at very high latitudes where the sun rises once a year?



  • I don't care how often it rises as long as the clock always says 06:00:00 when it happens.



  • That would break APIs that rely on days only being 24 hours, hours only being 60 minutes, and minutes being only (up to) 61 seconds long.

    (and yes, the latter two of those are totally unrelated to this, but a properly designed API has to be able to accept there may be more than 60 seconds in a minute due to leap seconds)


  • FoxDev

    @anonymous234 said:

    "every timestamp happens exactly once"

    Even on a system that sticks rigidly to UTC, you'll still get duplicated timestamps, unless you're recording to the femtosecond or something equally stupidly precise.



  • "Every timestamp happens exactly once" is better translated as "any given timestamp value refers to only one time interval". The point is avoiding the ambiguity between e.g. the 2:23:00am that occurs in the hour before daylight saving ends and the 2:23:00am that occurs in the hour after.

    This is an issue when recording timestamps in local time with no accompanying tz, as Windows still does for file modification times on non-NTFS filesystems.



  • @RaceProUK said:

    Even on a system that sticks rigidly to UTC, you'll still get duplicated timestamps, unless you're recording to the femtosecond or something equally stupidly precise.

    We should simply move to Planck time as the base unit.



  • @flabdablet said:

    Assuming all installed systems have up-to-date tzdata, the only scenarios I can think of where a localtime hwclock could actually cause me grief involve physically moving to a new tz between OS shutdown and startup, or having daylight saving start between shutting down Linux and starting Windows (which will then start up timestamping files an hour too late, then step time backwards by an hour as soon as w32time contacts an ntp server).
    Not quite. Since each OS "compensates" for being off during the change independently of the others, and since inexplicably none of them coordinate using the IS_DST flag in the RTC, you'll always have grief booting either OS after a transition. Granted, it'd be limited to "until ntpd/w32tm Saves The Day", but it's still going to happen every time, not just in extremely rare circumstances.


  • FoxDev

    @Maciejasjmj said:

    We should simply move to Planck time as the base unit.

    Yeah, but then someone will come up with the milliPlanck, and it'll just descend into chaos again 😿


  • FoxDev

    ah but that's the thing, we cannot differentiate the occurence times between events that occur "less than" one unit of plank time apart. as best we can figure out/calculate the plank time is the smallest possible unit of time there is because quantum physics.



  • I was working with an adserver API that took a different number of hours out of the month covering the spring clock-changing period depending on whether you used the preset number of days for the month or the custom number of days.

    Presumably the inconsistency was due to the preset measuring in hours, at a guess.



  • @TwelveBaud said:

    you'll always have grief booting either OS after a transition.

    Debian does an ntpdate almost immediately after bringing up the network interfaces at boot time, and it's generally well and truly complete before any applications get going. Windows doesn't.


  • FoxDev

    @accalia said:

    ah but that's the thing, we cannot differentiate the occurence times between events that occur "less than" one unit of plank time apart. as best we can figure out/calculate the plank time is the smallest possible unit of time there is because quantum physics.

    You underestimate the Power of Weird Shit™ :P


  • FoxDev

    i thought quantum physics was weird shit?


  • Java Dev

    I've had my system set up with linux thinking UTC and windows thinking local time for a while (because I hadn't found the aforementioned registry entry, and windows was installed last). On the desktop, the windows clock indicated the correct local time about one day per month, and UTC the rest of the time. Linux was always correct.



  • NASA didn't have too much of a problem with Mars time...



  • @accalia said:

    ah but that's the thing, we cannot differentiate the occurence times between events that occur "less than" one unit of plank time apart. as best we can figure out/calculate the plank time is the smallest possible unit of time there is because quantum physics.

    "CNR"


  • 🚽 Regular

    @chubertdev said:

    NASA didn't have too much of a problem with Mars time...
    They weren't working on a factory or waiting for a bus on Mars either.

    And they've had problems using different units, which is the point.


Log in to reply