• Zygo (unregistered) in reply to betaray
    betaray:
    Elephant:
    your government decides that this year, daylight savings time starts on October 1st rather than October 15th as it has been.

    This is quite an unusual situation, but I would like to know how you would solve this without needing to change your code to reflect the new daylight savings rules? If you store your values in UTC/GMT, you're right the appointment will occur at the wrong time if the system is unable to determine the correct local time, but the reverse is also true. If you store the time as local time, but are unable to convert local time to system time correctly, the appointment will occur at the wrong time, but in the other direction.

    I have always been a fan of storing things in UTC and converting back to local time for display purposes. The situation you describe, where the relation ship between local time and universal time, changes is it's one weak point.

    In this case if you have something scheduled in the future and your relationship changes you will have to update all of your UTC times in the future, and you will now have two sets of rules for converting universal time into local time. If you store things as local time you need to jump through all sorts of hoops to insure you're getting the correct differences in times. Did the task that started on 2:00am on March 11th and finished at 2:01am on March 11 take 1 minute to complete, or did it take 1 hour and 1 minute? Woe be unto those that want to find the difference between the local time between two timezones without converting to UTC.

    To summarize, dalight savings time sucks.

    If we are dealing with times of events in the present or past then these issues go away, since we presumably know what rules are in effect now, and we hope that no government will retroactively change daylight savings time transitions in the past (just think of the potential for litigation...). History is littered with redefinitions of civil time by fiat, but problems arising from interpretations of old timestamps can be solved by having a sufficiently complete table of all the transitions.

    So the trick is to store future event timestamps as localtime plus some representation of the time zone. We need the time zone's legal designation, not just a numeric offset from GMT--the whole point of changing DST rules is that the offset changes, so we need to know who changed the rules, which means we need to know the originating government's identity. Heaven help us if a time zone ever splits into two distinct areas and we have to figure out which of our data came from which area...

    Intermediate time values and comparisons can still be done in UT (not UTC - UTC handles leap seconds, but most date/time code in computers doesn't), since the conversion rules between local time and UT presumably will not change during a transaction, so whatever the rules are the computations will be consistent except during the actual hours of transition (as long as the times only have to be accurate within a second per year relative to the current time). Fortunately there are few such hours and they tend to occur at times of day when people aren't scheduling appointments, so this is often not a problem. Any time zone can be used as a reference timezone provided that the time zone does not observe DST (several don't) or have any other nonsequential quirks in its assignment of seconds to hours.

    I'm not sure what happens to appointments that were scheduled for the second 01:30 AM local time on October 15th in the affected time zones, since that time of day has simply ceased to exist in those time zones.

    Time deltas between times before-and-during or during-and-after the two transition dates will be changed as well. Is an appointment that was originally two hours long and starts at 12:30 AM local time on October 1 now three hours long, or is it still two hours long but starts at 12:30 AM and ends at 1:30 AM?

    Suppose a lab schedules a job on a machine that will take exactly 25 hours starting at 09:00 AM local time on October 14th, and is due at 09:00 AM local time on the 15th? The lab commits to these start and delivery times (as local times in the local time zone) prior to the new time zone legislation taking effect. That job will now be finished late, as there are now only 24 hours between those two times, one less than there were at the time when the job was scheduled.

    If DST was sensible then a second would take 999.77168949771689497ms for the first six months of the year and 1000.22831050228310502ms for the second (except in leap years when it would be 999.77231329690346083ms and 1000.22768670309653916ms respectively). Most consumer clocks aren't that accurate anyway, so most people will still have to reset their clocks every few weeks to keep the right time even if their clocks did have a "DST" switch to adjust the running speed. Highly accurate clocks (e.g. those accurate enough to care that there have been ~22 seconds added to UTC between 1970 and today) already have to cope with all the time zone insanity (leap seconds, time zones, one-time historic corrections, perturbations in Earth's orbit around the Sun) and wouldn't blink at reporting time in seconds of varying lengths.

  • Zygo (unregistered) in reply to real_aardvark
    real_aardvark:
    A Non-Mouse:
    White Echo:
    The worst part is I am sure the programmer is proud of himself.

    Unfortunately there are many many bad programmers like that out there and their employers do not always realize they suck ever.

    There was a fascinating psych study done a few years back called 'Unskilled and Unaware of It' which drew the conclusion that complete idiots do not even posess the skill necessary to realize that they are idiots. You really need to learn a little first to see what a moron you are.

    Go on.

    There's me and about a quintillion other WTF readers who want to know the URL of this study, or at least some way to find it.

    It sort of encapsulates 95% of the WTFs on the site... and a depressingly large number of the comments (including mine).

    I think it was a winner, or at least a nominee, for the Ignobel prize ("results that shouldn't be reproduced" - not to be confused with a similar journal of "irreproducible results"). It was a real paper and the authors were quite serious about their research as I recall.

  • Mover (unregistered) in reply to Elephant
    Elephant:
    In reply to the "just use UTC" guys: That works part of the time. A problem situation is with appointments scheduled to the future. You schedule an appointment to October 10th, 9:00AM, six months in advance. In July, your government decides that this year, daylight savings time starts on October 1st rather than October 15th as it has been.

    If you stored it in UTC, your appointment just got rescheduled.

    If this was an appointment for an international conference call, you'd want it to be rescheduled...

  • (cs) in reply to Zygo
    Zygo:
    real_aardvark:
    A Non-Mouse:
    There was a fascinating psych study done a few years back called 'Unskilled and Unaware of It' which drew the conclusion that complete idiots do not even posess the skill necessary to realize that they are idiots. You really need to learn a little first to see what a moron you are.
    Go on.

    There's me and about a quintillion other WTF readers who want to know the URL of this study, or at least some way to find it.

    It sort of encapsulates 95% of the WTFs on the site... and a depressingly large number of the comments (including mine).

    I think it was a winner, or at least a nominee, for the Ignobel prize ("results that shouldn't be reproduced" - not to be confused with a similar journal of "irreproducible results"). It was a real paper and the authors were quite serious about their research as I recall.

    For anyone else who can't be bothered with hunting it down: https://thedailywtf.com/Comments/The_Abstract_Candidate.aspx?pg=2#87948 http://forums.thedailywtf.com/forums/thread/101043.aspx#101043 http://forums.thedailywtf.com/forums/thread/89063.aspx#89063 https://thedailywtf.com/Comments/Apply_Yourself__0x2e__0x2e__0x2e__at_WTFU.aspx#87097 http://thedailywtf.com/Comments/Virtudyne_0x3a__The_Digital_Donkey.aspx#96055

    Or a direct link to the paper: http://www.apa.org/journals/features/psp7761121.pdf

    HTH. [image]

  • (cs) in reply to Dave (not that one)
    Dave (not that one):
    Let's say you have a database server in Oklahoma, but it is queried by clients all over the world. A user in Tokyo creates a transaction that includes a date, and writes it to the database. A user in New York later reads that transaction and needs to know the time it occurred, in the New York time zone. How would you store and manipulate date/time in the database to ensure this could be done? Assume there are no stored procedures, and client code needs to determine the time.

    Hint: It may be useful to know the time on the SQL Server.

    What? Why do you need to know what the time on the SQL server is?

    If you want to display times on the local system, you should store your times on the server in UTC. The convert the times locally.

    But if you don't do that, and you store the times in the zone they were entered from, then you need to know the local time of the viewer, the local time of the creator, and the time. The is you need to know what time zone the time is stored in. You don't care what timezone the SQL server is in.

    The time zone of the SQL server is completely irrevelent.

    Take your example. The user in Tokyo creates a transaction that includes a date (I guess it sort of depends on who created the date value?) The guy in NY queries the database... But lets suppose, after the Tokyo dude created the transaction, but before the NY gal queueried it, the server itsel is moved to Paris? Now what do you do?

    Hint: don't store local time values, at least not without also storing a known time zone.

  • (cs) in reply to real_aardvark
    real_aardvark:
    Storing hard-coded date-time strings is a ludicrous way to synchronise transactions across a network. Apart from anything else, with UTC you can instantly see which timestamp precedes which. Try that with a string ...

    While I agree with most of what you said, you do realize that UTC is just a time. It can still be formated in a variety of ways. You can represent UTC as a string for example. And you can have UTC times BEFORE 1970 and AFTER 2038. you might not have a time_t representation of UTC before 1970 or after 2038, but that has nothing to do with UTC itself.

  • Rich (unregistered) in reply to Mover
    Mover:
    If this was an appointment for an international conference call, you'd want it to be rescheduled...

    Not if you are the CEO. Then everyone else can reschedule around you.

    Appointments should be specified and stored with a timezone. When the computer does any calculations, convert to UTC first.

    If the Japanese client knows that the appointment is 10am CST and CST is monkeyed with then the Japanese client knows that the appointment has moved. It the appointment is stored with the Japanese timezone then the American participants have to adjust. No problem

    The issue, as ever, is to analyze and use what is appropriate to the job and not come out with high-handed pronouncements about what is correct.

    Rich

  • vb++ master guru for you (unregistered) in reply to Elephant

    seriously, if you need this explained, go do computing 101

  • Bo, the ancient mainframer (unregistered) in reply to JMC
    JMC:
    are you insane?? most of the programs you use on a day-to-day basis are written in C...

    Now THERE's a good reason to get rid of C if I ever did see one!

    CAPTCHA: howdy. Heck, how did ya'll know that I recently spent time in Dallas?

    Bo

Leave a comment on “Time to Deprecate”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article