The usual areas of issues are XML, where a time ending in a Z is Zulu, UTC, not "local time". A time without a Z is "local time" (but local to which end? hence to be avoided). A time with ±HH:MM on the end is a specific time zone. We often see BT see a time and assume UTC when no Z, or local time when a Z it used and sent. It causes no end of issues. To be fair Talk Talk have similar issues on XML. We also see XML from BT with the Z explicitly but the time itself is local time and so everything ends up an hour out. Customers may have seen on clueless that target completion of work in summer is often 00:59:59 the next day (local time) as BT have sent a date/time ending in T23:59:59Z.
It amazes me that this is remotely difficult or not just fixed.
The other classic for a long time was the Microsoft Office invites that would always say meeting at time GMT, e.g. 15:00 GMT, when they meant 15:00 UK local time. So we would not be ready at 15:00 local time, expecting the conference call or whatever at 16:00 (i.e. 15:00 GMT).
This was made worse when Microsoft added a note along the lines of "Times in GMT do not reflect local daylight savings times" or some such, which to me explicitly states they really do mean GMT (UTC) and not BST in such cases. Madness.
Today I have someone in ops suitably annoyed as they normally finish by now, when BT wanted to co-ordinate a simple certificate change at 18:00 BST. At least, today, they finally confirmed the right time, eventually. This is not hard, honest.
Them:
We do not perform any cutover during business hours. We have the slot at 18 BST on Thursday , we can have the cutover if its fine for you.
Me:
18:00 BST (so therefore 17:00 local time for us here in the UK) on Thursday is fine for us although isn't that in business hours too? We can also do 18:00 UTC.
Them:
We can do at 18 BST today. I will send the invite shortly.
Me:
Ah, OK, I don't have Exchange so that invitation doesn't mean a lot to me, but parsing the text by hand it says: DTSTART;TZID=GMT Standard Time:20171123T180000 So, OK, it's 18:00 GMT. I can still do 18:00 GMT but it is an hour later than 18:00 BST. You have caused some confusion here. We are no longer in daylight savings and 18:00 BST and 18:00 GMT are an hour different from each other.
Them:
I am so sorry James. Yes that’s 18:00 GMT. Apologies for the inconvenience caused.
There are two sorts of people (also organisations and software).
ReplyDeleteThose who use the Olson database, and those who get time wrong.
All right, some are in both classes.
(Z is not the only lettered time zone; the US military used to use A-Y excluding J for specific zones. But RFC822 got the definition of single-letter zones the wrong way round, and nobody could be bothered to fix it.)
(Am I getting incompetent, or is it usual to have to do 5-6 captchas now?)
Only Z for XML as far as I know :-)
DeleteAnd no idea - I don't comment on my blog when not logged in as me...
When doing military signalling (UK) we were taught Z for GMT, and A for BST - so letters increasing with the positive offset from UTC+0
DeleteYou might want to look at A&A ticket NG17CD...
ReplyDeleteLOL, will do.
DeleteI have kept "It would fix itself in the autumn anyway" (which I do know was said in jest) in my library of limp excuses for why I'm not going to fix hard things.
DeleteIt is an excuse only available to people working in our timezone, of course!
I do not share your opinion that there's nothing remotely difficult about time-zones and calendars, I think they're really hard to get completely right, and one doesn't tend to have to look very far to find examples of getting it subtly wrong.
I don't think it helps working in the UK because for half of the year you can fail completely but appear to succeed.
The problem with Microsoft and the US in general is they have a name for their time regions. They say things like 17:00 EST and that means Eastern Standard Time, which is the name for the zone all year round. It can be in daylight savings time but doesn't have to be. Being Americans, they then assume the entire of the rest of the world works the same way and that BST is therefore British Standard Time and it might be in summer time and it might not.
ReplyDeleteI used to work for a Canadian company, I was writing time zone handling code for a set top box. They asked me what name they should give the UK timezone, was BST correct? It took me weeks to persuade them that a) BST is not correct and b) we don't have a name for our zone all year round. One problem, the server code they had written needed a name for each zone. We had to settle on "British" as a name, and to get that to work I had to persuade them to allow more than three characters because their server code assumed all timezone names were a three letter acronym (because they all are in the US and Canada).
Now try explaining Leap Seconds to people. Personally I think it would clarify all these uncertainties if we could book meetings in TAI :-).
I wrote code for a now defunct Canadian telecoms manufacturer. After several attempts I finally managed to code not only leap seconds but also the reverse. The ITU allow corrections so a minute can be less than 60s too.
ReplyDeleteLearn from the Unix design, when talking to humans don't use abbreviations like "GMT" or "UTC", talk about cities.
ReplyDeleteFor example when I am dealing with a mixture of Brits, Californians, Mexicans and Indians I can still say with no problems like "Oh yes, 1045 London time" nobody will think I meant "London time, except, arbitrarily add an hour for some reason". If they're not sure when "1045 London time" is, they will ask Google, which will tell them, in terms of their local time, because that's Google's job. And if they _do_ understand timezones, they will be fine too.
Windows still shifts the displayed time of all files by an hour every time we switch between BST and GMT.
ReplyDeleteHistorically, FAT stored local time.. it wasn't designed in a networked world and 'time' was just the time on your PC. When MS designed NTFS they were sensible and started storing UTC.. except they f..ed up the conversion in the Win32 API so it always applies the *current* timezone offset to any conversion to/from local time, which has the effect of shifting the display time of half the files on your filesystem twice a year. MS have refused to fix this for 'compatibility'.
It's worse if your filesystem is FAT (luckily, becoming less common) because if you ask for the UTC time of a file on NTFS you get what is stored.. on FAT it does the same incorrect local time->UTC conversion, so the UTC time is wrong half the time. This caused some interesting 'fun' when I was working on version control software, until we eventually wrote our own date routines that did it properly (not that hard, because Windows does have the raw data for start/end dates built in - Microsoft just don't use them).
You can fix modern windows boxes so that they understand that your bios speaks gmt and only gmt and the value stored in the hardware is nit to be frigged about with when summer time changes. That way you can like you live in purity, gmt-only.
ReplyDeleteI am a pastafarian, a follower of the Flying Spaghetti Monster and also an ordained ULC minister. I think all religions should have a few completely random made-up items of dogma, so I have proposed that Pastafarianism should require devotees to live a GMT/UTC life. Arrr. Praise His Noodly Goodness. Stick to your guns about GMT.
ReplyDelete