- Feature Articles
- CodeSOD
- Error'd
-
Forums
-
Other Articles
- Random Article
- Alex's Soapbox
- Announcements
- Best of…
- Best of Email
- Best of the Sidebar
- Bring Your Own Code
- Coded Smorgasbord
- Mandatory Fun Day
- Off Topic
- Representative Line
- News Roundup
- Editor's Soapbox
- Software on the Rocks
- Souvenir Potpourri
- Sponsor Post
- Tales from the Interview
- The Daily WTF: Live
- Virtudyne
Admin
Frist
Admin
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.
Admin
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 🤔
https://www.itpro.co.uk/network-internet/email-delivery/361896/y2k22-bug-breaks-microsoft-exchange-servers
Admin
At least David B. is lucky enough - by a couple of months - not to have to worry about eleven more days.
Admin
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.
Admin
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
Admin
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.
Admin
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.
Admin
Daylight savings time needs to die
Admin
But it needs to do it gradually, in different places, over the course of 5 years.
Admin
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.
Admin
Of course it can be negative! How else are you supposed to store dates before year 0?
Admin
There was no year 0. It goes from 1 BC straight to 1 AD.
Admin
I feel like Foone (https://twitter.com/Foone) would have something to say about the last one.
Admin
The year 1 BC would normally be stored as year -1. IOW, it's still negative.
Admin
Yeah, first year 50 minute change, second year 40 minute change, etc.
Admin
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.
Admin
And then add time zone into the equation. Which country switch to DST back and forth on what date in which time zone ...
Admin
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.
Admin
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.
Admin
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.