1. 10
  1. 4

    #The familiar %-based syntax we all know and constantly forget%Y-%m-%d

    I suppose this is sarcasm, since what the author probably wants is %y-%M-%d (year-month-day, as opposed to ISO week numbering year-minute-day).

    To put it briefly, avoid using local time like the plague. Because it will eventually fester into something that will hurt you. Store everything in UTC or something pegged to UTC like Unix time

    I’ve had to clean up the mess left behind by colleagues who followed this slavishly before. A lot of dates are only relevant as dates and not some abstract point in time that can be rendered as a timestamp in any time zone because it only represents a point in time.

    We had a system where the users were supposed to share their daily training results, yet the system didn’t keep track of when the day for the user began or ended. This was luckily discovered before going into production, but not before the colleague responsible for the setup had left the project.

    It also goes for booking systems, where you want your weekly 10 o’clock meeting to be at 10 o’clock every week in regardless of daylight savings time, though it may seem to shift back and forth as seen from a user in another time zone.

    I think what you must keep in mind is if the dates and times you are dealing with are just points in time or if they are dates in a calendar. Regardless there are a lot of cases where storing time as UTC is a downright bad idea.

    1. 3

      It also goes for booking systems, where you want your weekly 10 o’clock meeting to be at 10 o’clock every week in regardless of daylight savings time, though it may seem to shift back and forth as seen from a user in another time zone.

      This is even more fun if you have a meeting with folks in different time zones. Since the US introduced George W. Bush Golfing Time, there are a few weeks in the year where daylight saving time is not aligned in the EU and US. It is impossible to schedule a meeting with remote participants in both places that doesn’t move by an hour for at least some of them and then shift back again a couple of weeks later. You need some mechanism to clearly express to users what they should expect when this happens.

      I made the mistake of flying the first day that GWBGT was introduced and discovered when I landed in the US that my connecting flight left 20 minutes before I was scheduled to land, not 40 minutes after, and the booking system hadn’t noticed this because it hadn’t been updated. Fortunately the second flight was a short hop that ran every hour and there was space on the next one, though that staff at the desk were quite rude and seemed to think that it was my fault that their software had sold me a ticket for a flight that landed an hour after the booking confirmation said it would.

      Most calendaring software really struggles with the idea that events can start in one time zone and end in another, which makes me wonder if the authors of them ever travel. If you’re flying anywhere then there’s a good chance that your flight will take off in one time zone and land in another. Outlook seems to manage this (but can’t then display the calendar UI in the other time zone after arrival), most other things I’ve tried require me to entry both times in a consistent time zone, which often leads to difficulties. Storing these as UTC or UNIX time stamps is fine, the difficult bit is in the UI layer, ensuring that I can enter a date with the right time zone and that it understands that the concept of my local time zone may change depending on the current time.

      I’ve never been in a situation where I’ve needed an event that started in one calendar but ended in another. Most software can probably ignore this corner case but historians have to deal with this kind of thing quite often (and even where things end up in a single calendar, details of a calendar can leak and leave you with an October Revolution in November).

      Oh, and if you have to deal with physics then the fact that there is no global absolute time can become more of a headache and we should be glad to have only the problems in the article!

      1. 3

        I suppose this is sarcasm, since what the author probably wants is %y-%M-%d (year-month-day, as opposed to ISO week numbering year-minute-day).

        %y-%M-%d would mean “2 digit year”, “minute”, and “day”. %G is the code for the 4-digit ISO week year.

        (source: man strftime).

        yyyy vs YYYY is that utterly stupid Java thing that was posted here a couple weeks ago.

        1. 1

          Sorry, the irony is on me. I had it confused with the formatting templates specified in the Unicode standard: http://www.unicode.org/reports/tr35/tr35-31/tr35-dates.html#Date_Format_Patterns

          1. 1

            Yeah, those look similar to the Java codes.

        2. 1

          To take it a bit further: There are points in time, and then there are patterns against points in time, as I understand it. A date, then, is a pattern against points in time, that represents many of them, kinda like a cronjob recurrence pattern.