• View all 0 comments (unregistered)


  • Tim Ward (unregistered)

    At one point in the 1980s, Australia changed their summer time schedule with a few weeks' notice (something to do with a visit by the Queen). This didn't upset the internet, because Arpanet wasn't that much of a thing at the time, but it didn't half confuse the airlines - my ticket was issued before the change, and whilst in Singapore I got a phone call to tell me that my flight back to Europe was going to be an hour different to what it said on my (paper) ticket ... but of course they got the hour's difference the wrong way round. Never mind, now that it's an airport and not a PoW camp Changi is not the worst place in the world to waste two hours.

  • Robin (unregistered)

    It seems there really is a Y2K22 problem for companies that convert date strings to YYYYMMDD integers and store them in a 32-bit field. There's a small-ish hobby site I know of that had this problem (I won't name and shame them here), but then I read that they weren't the only ones. It's of course unreasonable to expect Microsoft to have the resources to spot that there might have been an issue coming and change the database before the system crashes and burns 🤔


  • RLB (unregistered)

    At least David B. is lucky enough - by a couple of months - not to have to worry about eleven more days.

  • Brian (unregistered)

    I had a Windows phone back when those were a thing, and I found myself being an hour late to certain appointments that had been scheduled well in advance. I finally figured out that the calendar didn't handle the changeover from standard time to DST very well - adding a calendar entry before the switch for an event that happened after got things all out of whack.

  • (nodebb) in reply to Robin

    It seems there really is a Y2K22 problem for companies that convert date strings to YYYYMMDD integers and store them in a 32-bit field.

    Not exactly. The site claims that Exchange is storing the dates at Y,YMM,DDX,XXX where the XXXX part is either a sequence number or HHMM for hours and minutes, with the example date/time (2,201,010,001) being 00:01 on 1 January 22. If it was just YYYYMMDD, that would work just fine, since a date in 2022 would be a bit more than 202 million, far short of the limits of 32 bit fields.

    And the problem isn't that it's 32-bit, but that it's 32-bit signed.

    Addendum 2022-01-07 09:26: See https://techcommunity.microsoft.com/t5/exchange-team-blog/email-stuck-in-exchange-on-premises-transport-queues/ba-p/3049447 especially the post by John_C_Kirk

  • RLB (unregistered) in reply to Steve_The_Cynic

    And the problem isn't that it's 32-bit, but that it's 32-bit signed.

    Well. TRWTF is that they're storing a date in that way at all. If you must, for some reason, store dates (not timestamps) as numbers, at least use JDN.

  • (nodebb) in reply to Brian

    Yes, Outlook had the same problem. If you set a recurring appointment for 9 a.m. EDT, it would stay at 9 a.m. EDT--which is 8 a.m. EST--even after you switched to standard time for the winter. Fixed now, thank goodness.

  • (nodebb)

    Daylight savings time needs to die

  • tbo (unregistered) in reply to Mr. TA

    But it needs to do it gradually, in different places, over the course of 5 years.

  • Robin (unregistered) in reply to Steve_The_Cynic

    Yes, thanks - I realised after posting that my details weren't quite right. And yes, using a signed integer for an artificially constructed number that can never be negative is an aspect I hadn't considered, which makes this full on worthy of an article on this site, in my opinion.

    I mean it's a WTF either way but at least they'd have been safe tile 2043 if it were unsigned.

  • Mr. T (unregistered) in reply to Robin

    Of course it can be negative! How else are you supposed to store dates before year 0?

  • MRAB (unregistered) in reply to Mr. T

    There was no year 0. It goes from 1 BC straight to 1 AD.

  • (nodebb)

    I feel like Foone (https://twitter.com/Foone) would have something to say about the last one.

  • Sou Eu (unregistered) in reply to MRAB

    The year 1 BC would normally be stored as year -1. IOW, it's still negative.

  • Randal L. Schwartz (google) in reply to tbo

    But it needs to do it gradually, in different places, over the course of 5 years.

    Yeah, first year 50 minute change, second year 40 minute change, etc.

  • Officer Johnny Holzkopf (unregistered) in reply to Randal L. Schwartz

    Depending on country - every country needs to independently define when "first year" takes place, and the next year doesn't have to be the "second year", because that's how bureaucra-, erm... democracy works.

  • Hasseman (unregistered)

    And then add time zone into the equation. Which country switch to DST back and forth on what date in which time zone ...

  • gnasher729 (unregistered)

    Most years a few MacOS and iOS applications display the wrong year in the few last days of the year or the first days of the new year. The reason is calendar weeks: Up to three days of the previous year can be in the first calendar week of the new year, and up to three days of the new year can be in the last calendar week of the old year. And there are two formats for the year: "YY" or "YYYY" and "yy" or "yyyy". One shows the actual year, the other shows the year of the current calendar week. So if January 1st is in the last calendar week of the previous year, one of the formats will show the last year.

    And every year there is a new set of programmers getting it wrong.

  • DJ Dizzy Spudplucker (unregistered) in reply to RLB

    32 bits? 3 for the month, 4 for the day, 25 bits for the year (signed), gives you from 16.7 million BCE to the year 16.7 million.

  • Dlareg (unregistered) in reply to Brian

    That makes me think of the time we used lotus notes. It would make the appointments in the timeline you were in even if the colleague (so same severs) was in a different one. But did not change it when you traveled. So when in Athens making an appoint ment at 1300 with a colleague in Amsterdam at 13:00. It would put it at 15:00 in my agenda. Then when travelling to Amsterdam for the meet it would still be at 15:00. When working regularly in 3 or 4 different timezones a week. It messed my schedules horribly.

Leave a comment on “Everything Old is New Again”

Log In or post as a guest

Replying to comment #:

« Return to Article