Daylight Saving Time woes

  1. ‹ Older
  2. 2 weeks ago

    Beatrix W

    Mar 10 Pre-Release Testers Europe (Germany)

    I don't understand the problem. The computers in California will get their own locale. Even without the locale a computer has a current time. Doesn't even matter which time. You can calculate the difference to UTC.

    Additionally, there is a database for DST. If your computers don't have access to the internet you could read this database.

  3. Christian W

    Mar 10 Pre-Release Testers Los Angeles, CA
    Edited 2 weeks ago

    @Beatrix W The computers will get their own locale except for those that are not getting updates. But those who don't get updates that remain on the PST locale will get the incorrect UTC delta.

    Consider that today a computer in California will get a UTC difference of -7.

    But in November, assuming California has implemented always-on DST (still unknown when it will be implemented despite voter approval), a computer that has not been updated will fall back an hour.

    The user may realize events are an hour late because of the time change that no longer occurs in California and will then manually change the system clock to compensate. But the locale rules of a computer that has not been updated will return a UTC difference of -8 when it still should be -7 and my application will still trigger events one hour late if I base the triggers on UTC time instead of local time.

    I should mention that this application caters to the farming industry and interfaces with field hardware. Many of my users will not have internet access to update their OS, update the application, or contact a time server.

    I greatly appreciate everyone's thoughtful suggestions!

  4. Dave S

    Mar 10 San Diego, California USA

    @Christian W But in November, assuming California has implemented always-on DST (still unknown when it will be implemented despite voter approval),

    I too live in California... but was under the impression that while "we" voted to stop switching.... the legislature had to decide WHICH side of the line to "keep"....do we stay with what we have today (we changed last night).... or do we go back to what it was a few days ago? Either way.. my understanding was it would be a "few years" before all the consequences were hammered out, including needing to be approved by Congress.

    https://www.usatoday.com/story/news/nation/2019/03/08/california-daylight-savings-time-clock-change-legislation-could-end-dst/3102444002/

  5. Christian W

    Mar 10 Pre-Release Testers Los Angeles, CA

    @Dave S CBS Sacramento suggests that this may be it.

    https://sacramento.cbslocal.com/2019/03/06/daylight-saving-time-california/

  6. Dave S

    Mar 10 San Diego, California USA

    “Effective immediately after federal law authorizes

    I have never known Congress to move that fast.... so not holding my breath quite yet :)

  7. I guess I'm off the track. Anyway, using macOSlib I can know if a location supports DST and if at a given date/time DTS for such location is On or Off.
    But as I said, I may be completely off the track.

  8. Dave S

    Mar 10 San Diego, California USA

    Carlo... the issue is surrounding the fact that "soon" California will be opting out of DST (like parts of Arizona already do).... And that it will take some period of time for macOS/Windows etc to update the latest versions of their OS to deal with it... not to mention anyone that is NOT running the most up to date OS (including iOS) will get wrong time information for California after that transition.

    So what macOSLib tells you now.... could be wrong for some users in the future.

  9. @ Dave Sisemore
    Thank you Dave for making the issue clearer.

  10. Robin L

    Mar 11 Xojo Inc Europe (Germany, Rehlingen)

    Europe will be doing the same thing. The problem here is that each state will be allowed to decide whether to keep Summer or Winter time! :D

  11. Jeff T

    Mar 11 Midlands of England, Europe

    But UTC is Universal Time Code.
    It is basically GMT. Always
    No matter what the local decision is.

    Even Britain doesnt stay on GMT ( at the moment).
    So when we go to Daylight Savings, GMT and UTC are out by an hour.
    If you always work in UTC, it 'just works'

    Unless you are saying that your app needs to do something and then react to whatever LOCAL time is, rather than elapsed time?

  12. Emile S

    Mar 11 Europe (France, Strasbourg)

    And what about the computer date is wrong (because its battery is off) ?

    Also, in Europe (AFAIK), the changes will happens in the night of the last March Sunday (2:00 --> 3:00) and back in the last October’s Sunday (if my memory is correct).

    Since some years, my computers change the DST by themselves (it was not always the case); my non smart telephone have to be changed manually.

    This is the first time since DST appeared in France (1976) that I saw this question. (Yes, you now know that I do not understand what the trouble is/can be).

  13. Dave S

    Mar 11 San Diego, California USA

    @Jeff T But UTC is Universal Time Code.
    It is basically GMT. Always
    No matter what the local decision is.

    But your average person doesn't use (or care) about GMT. they want to know what Time it is, where they are...

    @Emile S Since some years, my computers change the DST by themselves

    The point here is... those computers won't KNOW anymore (unless they get an OS upgrade)

  14. Jeff T

    Mar 11 Midlands of England, Europe

    they want to know what Time it is, where they are...

    People do, this is true.
    So far, Im finding it hard to pick out what it is that the OP's app actually does.
    Is it using the time in order to just 'do stuff on a scheduled basis', or does it report the local time as it does so?

    And essentially Im saying use UTC as a guide to what the 'time since...' is
    Then do something and tell people what the local time is

  15. Dave S

    Mar 11 San Diego, California USA

    @Jeff T Then do something and tell people what the local time is

    and there in lies the problem. Unless the rules in the current OS are correct you cannot do that.
    and those rules won't be correct for older versions of an OS, or until the vendors issue a new one...
    but should California decide by November.... I doubt Apple or Microsoft will update on that day .... meaning the auto adjustment of all computers will be wrong for at least some period of "time" (pun intended)

  16. Dale A

    Mar 11 San Diego, California, USA

    I don't know the answer but this problem must have already been solved. How do systems in Arizona handle it since Arizona does not recognize Daylight Saving Time (except for a few of the Indian Reservations) while the rest of the Mountain time zone does.

    A little investigation on timezone names shows that most of the Pacific timezone is derived from "America/Los Angeles". This means that if California does go all Pacific Daylight the rest of the timezone will have to pick a new baseline abbreviation.

  17. Dave S

    Mar 11 San Diego, California USA
    Edited 2 weeks ago

    @Dale A How do systems in Arizona handle it since Arizona does

    because AZ is already built into the DST rules of all major operating systems..... but California opting out is not

    and Pacific Time zone is the entire West Coast of the United States and most of the western edge of Canada....
    so California will need its own brand new Timezone :)

  18. John F

    Mar 11 Pre-Release Testers, Xojo Pro Omaha, Nebraska

    There is discussion in Congress to eliminate day light savings time and President Trump has indicated he is also in favor of it. Might want to wait a while to see if it goes the way of the floppy disk.

  19. Dave S

    Mar 11 San Diego, California USA

    Either way Congress still has to approve it.... California voters just approved it a few months ago... Florida voters approved theirs well over a YEAR ago, and Congress has yet to act.....

  20. Wayne G

    Mar 11 Pre-Release Testers, Xojo Pro New Zealand axisdirect.nz

    Sometimes it's just great living in NZ where we have two timezones NZ & CHA and I can ignore the CHA timezone as less that 1000 people live there.

    Core.Date abstracts us from these issues though and moves the problem down to the OS vendor level.

    Taking this conversation into account I'll probably add a clause to my EULA to cover the OS vendor not being agile enough to fix the problem in a timely fashion. OS's not up to date are already covered.

    As for the concept of daylight saving I love it! We should have it all year round which is the same as not at all I suppose. I don't care about going to work in the dark in winter (but then it's only a walk down the stairs :))

or Sign Up to reply!