Daylight saving time



  • You'd think that, in 2014, you wouldn't have to worry about things light daylight saving time, because your computers take care of it automagically. And you'd think wrong.

    Today, I spent a considerable amount of time trying to figure out why some automated tests where suddenly failing. The thing is, these are Java-plus-Hibernate self-integration tests that test a bunch of Oracle PL/SQL procedures.

    One of these tests involves checking that a certain operation has failed for the past 10 days and therefore needs to be cancelled. Now date arithmetic is dead easy in Oracle: you just do SYSDATE-10. Tada, 10 days, or more precisely, 240 hours, get subtracted from the current time.

    Which works just fine most of the year, except for that period in October where 10 days actually equate 241 hours.

    Sigh...



  • Windows seems to fail at understanding DST, possibly.
    When I woke up yesterday, the time on my Laptop was 6:15AM, same as on my phone and 1 hour before the analogue alarm clock I've previously posted a photo of here.
    About 15 minutes later, I decided to reboot my PC into Windows 8.1 (when I woke up it was still booted into Xubuntu) and was surprised when the time was not 6:30AM but 5:30AM.

    Apparently, the automatic time synchronization with time.windows.com - which is the default server - is broken. But switching to NIST fixed it. And if Windows knows that it's not DST anymore, it seems like it will just subtract an hour and hope for the best.



  • Nah... it's not that. And it appears that my claim about SYSDATE arithmetic isn't correct either. But it still doesn't explain what's going wrong. Quite vexing, really.


  • Discourse touched me in a no-no place

    @Severity_One said:

    except for that period in October where 10 days actually equate 241 hours.

    And the period in March where 10 days = 239 hours.



  • Um, I was trying to derail this into a general discussion of how broken by design (and implementation) DST is.
    Not a talk about Oracle on Windows - which I know nothing about.


  • FoxDev

    @aliceif said:

    Abotu 15 minutes later, I decided to reboot my PC into Windows 8.1 (when I woke up it was still booted into Xubuntu) and was surprised when the time was not 6:30AM but 5:30AM.

    Both Xubuntu and Windows behaved correctly. The problem is that they both adjusted the BIOS clock.

    It should be possible to force one or the other not to adjust the BIOS clock. I know it can be done in Linux, at least if I remember rightly from when I used to dual-boot.



  • Um, I had network time activated in Windows.
    Wouldn't it, like, sync on startup?


  • kills Dumbledore


  • FoxDev

    @aliceif said:

    Wouldn't it, like, sync on startup?

    why would it bother? Wondows knows that it's going to be the only OS on the computer anyway. so it knows that the only one that could have possibly toughed the BIOS clock last was itself.

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



  • @loopback0 said:

    And the period in March where 10 days = 239 hours.

    No, because it fails after 240 hours, so also after 239 hours.

    The real WTF is much simpler: yours truly. You can do SYSDATE - 10 in Oracle, and it compensates, but if you do new Date( new Date().getTime() - 864_000_000L ) in Java, things go belly up.

    Yes, the deeper issue is that date handling in Java is still a complete mess, and yes, I'd probably should be using Joda Time, but still, this is something that I should have thought about.




  • Banned

    The main problem with Windows not handling DST correctly is that it sets hardware clock to local time. If it used UTC (like Linux by default), all problems related to timezones would go away... Okay, most problems.

    TRWTF is daylight saving time in 21st century.



  • I am just annoyed that Nintendo hasn't learned how to implement this at all. Windows freaking 95 knew how to do it! They have no excuse.



  • @aliceif said:

    Um, I had network time activated in Windows.
    Wouldn't it, like, sync on startup?

    Most NTP implementations don’t sync on startup because they use complicated algorithms to estimate the time server’s network lag.



  • time.windows.com is always broken. I have Windows servers that can't sync with Microsoft because they are 10 seconds ahead. No issue with nist ever.



  • Any one with a Lumia care to check if their time has changed? Maybe MS ditched time.windows.com in that particular OS.



  • Phones generally get their time from the cell network, don't they?


  • FoxDev

    which, FWIW, is rarely anywhere close to the correct time. I've seen drifts as extreme as 10 minutes. average drift appears to be 2 minutes.


  • FoxDev

    @Gaska said:

    The main problem with Windows not handling DST correctly is that it sets hardware clock to local time. If it used UTC (like Linux by default), all problems related to timezones would go away... Okay, most problems.

    TRWTF is daylight saving time in 21st century.


    Windows uses UTC internally as well. And saying Linux is somehow better at handling DST... well, it isn't. Unless you tell it to set the hardware clock to UTC, it'll still set it to local time. Just like Windows. And OS X. And [insert OS name here].


  • ♿ (Parody)

    @Severity_One said:

    but if you do new Date( new Date().getTime() - 864_000_000L ) in Java, things go belly up.

    Yeah, I had some tests written by someone else a couple of years ago that did something similar. Took me a while to figure out WTF was going on.

    @Severity_One said:

    Yes, the deeper issue is that date handling in Java is still a complete mess, and yes, I'd probably should be using Joda Time, but still, this is something that I should have thought about.

    Yeah, we still use Calendars (and a few Date objects still about, but manipulation happens with Calendars), and as long as you use the add() method with appropriate units it all seems fine.


  • Java Dev

    Linux uses UTC system clock by default, except when initially installed next to a windows installation.

    I've got my home dual boot set up so that both OSes use a UTC clock - there's a windows registry setting somewhere.



  • @Gaska said:

    TRWTF is daylight saving time in 21st century.

    It makes sense in the more northern (or southern, if you're in the southern hemisphere, although the land mass doesn't extend so far as it does with Eurasia) latitudes. The USA/Canadian border is around the 49th parallel; in Europe, that would be around Paris, or southern Germany. There are quite a few people living north of that; the whole of the UK for example.

    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.

    In summer, at those latitudes it would be light from 5 AM to 10 PM, give or take, and the idea is you'd be using less electricity because you switch on your incandescent lights later. Except that incandescent lights are nowadays banned in Europe.



  • @RaceProUK said:

    Both Xubuntu and Windows behaved correctly. The problem is that they both adjusted the BIOS clock.

    It should be possible to force one or the other not to adjust the BIOS clock. I know it can be done in Linux, at least if I remember rightly from when I used to dual-boot.

    @accalia said:

    why would it bother? Wondows knows that it's going to be the only OS on the computer anyway. so it knows that the only one that could have possibly toughed the BIOS clock last was itself.

    This is so much fun on our multiboot test boxes that have 3 different versions of Windows and eleventy-billion versions/distros/kernels of Linux. The system clock on those machines is probably sufficient entropy for a cryptographic random number generator.



  • @Severity_One said:

    No, because it fails after 240 hours, so also after 239 hours.

    The real WTF is much simpler: yours truly. You can do SYSDATE - 10 in Oracle, and it compensates, but if you do new Date( new Date().getTime() - 864_000_000L ) in Java, things go belly up.

    Yes, the deeper issue is that date handling in Java is still a complete mess, and yes, I'd probably should be using Joda Time, but still, this is something that I should have thought about.

    Why yes, if you use an object who has no notion of timezones and start doing math on it, it's going to cause issues. This is why even stock Java has the Calendar (well... GregorianCalendar) class.

    ...and that's without even talking about JodaTime or Java 8's new time library.



  • @Severity_One said:

    incandescent lights are nowadays banned in Europe

    Half-truth.
    Incadescent halogen lightbulbs still exist and aren't being planned to be banned yet.
    And MR16s are pretty popular in Germany.


  • Banned

    @Severity_One said:

    It makes sense in the more northern (or southern, if you're in the southern hemisphere, although the land mass doesn't extend so far as it does with Eurasia) latitudes. The USA/Canadian border is around the 49th parallel; in Europe, that would be around Paris, or southern Germany. There are quite a few people living north of that; the whole of the UK for example.

    I live in Poland (51°N) my whole life and still think DST shouldn't be a thing.

    @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.

    Winter time is the default. No need to justify it. Besides, it's pitch fucking dark at 7AM in December in either time.

    @Severity_One said:

    In summer, at those latitudes it would be light from 5 AM to 10 PM, give or take, and the idea is you'd be using less electricity because you switch on your incandescent lights later. Except that incandescent lights are nowadays banned in Europe.

    Also, electricity is cheap. See my point now?



  • @Severity_One said:

    10 days, or more precisely, 240 hours

    BZZZZT

    Wrong!

    Times are not dates, and dates are not times, despite the fact that a date and a time and a timezone can be bundled together as a timestamp represented as a single number.

    If you want to subtract a certain number of days from the date portion of a timestamp, subtracting some presumed-equivalent quantity of hours or minutes or seconds or milliseconds or nanoseconds is Doing It Wrong. Use your date/time library's differencing function, and tell it that the difference is in days. Those functions accept those parameters in the way that they do for good and sufficient reasons.

    Treating every specifiable timestamp difference as if it were always equivalent to some predictable constant number of timer ticks is a brain fart of the same kind, though not quite of the same boneheadedness, as the recent Error'd piece where the Fahrenheit temperature scale's 32° zero offset wrt Celcius got included in a temperature difference expressed in both scales.


  • FoxDev

    this is exactly why i always specify timeouts/time windows in my programs as either milliseconds or seconds (depending on the expected range of values.)

    if you want really long timeouts then you can have them, but i'm only counting seconds and you'll just have to deal with the possibility of DST or leap seconds happening.



  • @RaceProUK said:

    It should be possible to force one or the other not to adjust the BIOS clock. I know it can be done in Linux, at least if I remember rightly from when I used to dual-boot.

    The usual setup for Windows + Linux dual boot boxes still has both of them setting the BIOS clock on exit, but you tell Linux to set it to local time instead of UTC; this is usually an /etc/adjtime option in recent distros. I don't know of a reliable way to persuade Windows to treat the BIOS clock as UTC.



  • @aliceif said:

    Um, I had network time activated in Windows.Wouldn't it, like, sync on startup?

    Windows network time sucks, especially if you're expecting it to work like ntp. It doesn't. It works more like applying a heavy blow to the back of the CMOS clock's head every half an hour with an ntpdate brick.

    If you want a system to test your code on to see how badly it breaks on backward time steps, Windows is for you.



  • Well, the thing is, this wasn't the program, but the self-integration test. It doesn't need to be so rigorous, or otherwise you'd have to write a test package for your test package.

    Don't worry, I've converted everything now, and lo and behold, everything is working again. I just wish that dates and times in Java <= 7 would be a bit easier. And it's an easy mistake to make, because in your mind you think you're doing the same thing in Java as in Oracle. Which you aren't, but it isn't obvious.



  • @accalia said:

    Wondows

    There is a bar in Madison by this name (spelled differently), best known for their "fishbowl"

    Yes, it's exactly what it sounds like. A fishbowl full of alcohol. They've also been known to mix fishbowls in other objects. Like the Stanley Cup.



  • @delfinom said:

    I have Windows servers that can't sync with Microsoft because they are 10 seconds ahead. No issue with nist ever.

    All workstations on LANs I manage are set to sync with the ntp server in the default gateway, which is itself set to sync with several instances of au.pool.ntp.org (.pool.ntp.org addresses are round-robin). I too have been bitten once too often by time.windows.com.



  • @Severity_One said:

    I just wish that dates and times in Java <= 7 would be a bit easier made any kind of coherent sense whatsoever.

    FTFY.



  • @Severity_One said:

    you'd have to write a test package for your test package.

    You're very clever, young man. It's test packages all the way down!



  • @accalia said:

    i always specify timeouts/time windows in my programs as either milliseconds or seconds

    Lovely for as long as you can get away with it. Eventually you're going to hit a business logic requirement, such as the length of a contract, where a date interval is specified in days or (worse) months. DO NOT convert any such interval to seconds. Just don't. Let your date/time library deal with it; it's above your pay grade.


  • FoxDev

    oh. in those cases there have also always been the business requirement that salespeople can alter the length of the contract in the UI for reasons that confuse the hell out of me because the start/end date have no bearing on what we charge.... so i just put date pickers and let the sales people figure it out. they use proper date time stuff and IIRC default to start today+31 and end today+31+365





  • @accalia said:

    default to start today+31 and end today+31+365

    BZZZT error. Please replace with today + 1 month and today + 1 month + 1 year respectively.


  • FoxDev

    i would have done that yes. but the business wanted 31 days explicitly and they also didn't want +1 year either. even though if it crosses leap year they always edit in that extra day anyway. I think they just don't trust IT...

    i would have prefered today+ 1 month and today+1 month + 1 year but business sayd must do it by days, and that fight was way above my paygrade.

    i did break out those adjustments into a common place that's self encapsulated so when (and it is when) they decide to change their mind i only have to update all those date time rules in one place.



  • @accalia said:

    business sayd must do it by days, and that fight was way above my paygrade.

    Sigh.

    Always so tempting to implement it properly but make sure the demo happens during a 31-day month in a 365-day year :)

    Filed under: CANNOT REPRODUCE, RESOLVED INVALID


  • FoxDev

    if theres a trust issue i'm not feeding it.

    they says days, they said it again when i suggested saner adjustments. so i did what they said and made it easy to change when they decide they liked my suggestion better after all.



  • @accalia said:

    when they decide they liked my suggestion better after all.

    In my experience, it usually takes those types about two weeks from your initial suggestion to realize that they have just had this really good idea about how to improve the system's default date picker 😄

    Filed under: Just tryin' to plant seeds... ya try, ya do what ya can


  • FoxDev

    we'll see. i ain't changing the default date picker tho. nope. not rolling a custom winforms control for that. the best i'll do is customize when the default date is.


  • BINNED

    @flabdablet said:

    Filed under "low and behold" is a basic tenant of grammar for all intensive purposes and must be reigned in

    Grammar/spelling anti-patterns thread?



  • And if it seems hard with a single timeline, imagine if we had to take relativistic effects into account!

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



  • @Severity_One said:

    One of these tests involves checking that a certain operation has failed for the past 10 days and therefore needs to be cancelled. Now date arithmetic is dead easy in Oracle: you just do SYSDATE-10. Tada, 10 days, or more precisely, 240 hours, get subtracted from the current time.

    Which works just fine most of the year, except for that period in October where 10 days actually equate 241 hours.

    I don't get why that causes a problem. The jobs have to have failed for 10 days or more, surely... right? So it would have a greater-than, and the only failure would be the detection takes an hour "longer" (by some reckoning I guess, not by the clock on the wall) to hit the limit.



  • @aliceif said:

    Um, I had network time activated in Windows.Wouldn't it, like, sync on startup?

    Ok, two things:

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

    2. Network time servers don't know what time zone you're in, and therefore don't know if Daylight Saving Time is applicable to the client or not. Windows syncing with the network time server isn't going to (necessarily) solve the issue you're having. Definitely won't if Windows is set to the wrong time zone.


  • Java Dev

    Did a quick google, which returns https://wiki.archlinux.org/index.php/Time#UTC_in_Windows as the top result. Which is the registry edit I recall doing in windows 7 (and has worked fine for years).


  • I survived the hour long Uno hand

    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.


Log in to reply