Our favourite telco make use of microsoft tools to arrange calls and meetings.
It is now A&A company policy that if we get an invite to a conference call or a meeting that says, for example :-
When: 08 August 2011 11:00-12:00 (GMT) Greenwich Mean Time : Dublin, Edinburgh, Lisbon, London.
We are to take it at face value, in that case 12pm local time (BST). Especially if the email has the caveat :-
Note: The GMT offset above does not reflect daylight saving time adjustments.
Which makes it very very clear they really do mean GMT and not local time that would reflect local daylight savings time adjustments.
(unless the meeting or call is for our benefit not theirs, obviously).
Why do big corporates like BT plc not refuse to pay microsoft until they fix this simple buglet? I would if I used microsoft...
What amazes me is that the "Note: The GMT offset above does not reflect daylight saving time adjustments." is clearly new and somehow an attempt to address the error but, in my view, just makes it worse by making it clear you really did mean GMT!
Subscribe to:
Post Comments (Atom)
Fencing
Bit of fun... We usually put up some Christmas lights on the house - some fairy lights on the metal fencing at the front, but a pain as mean...
-
Broadband services are a wonderful innovation of our time, using multiple frequency bands (hence the name) to carry signals over wires (us... -
For many years I used a small stand-alone air-conditioning unit in my study (the box room in the house) and I even had a hole in the wall fo... -
It seems there is something of a standard test string for anti virus ( wikipedia has more on this). The idea is that systems that look fo...
There are two issues here. The second is simplest - in certain circumstances the time is sent unadjusted so Microsoft introduced that extra text in Outlook 2007 SP2 to try to resolve the ambiguity, but it's basically gibberish and makes an occasionally bad situation into a universally bad situation so they thought better of putting it into Outlook 2010 (which BT's licence agreement almost certainly entitles them to but it's obviously far too new to be trusted).
ReplyDeleteThe first and bigger issue is one of terminology. We think of GMT and BST as two distinct timezones, BST being "one hour ahead of GMT". In other timezones there may or may not be a separate name for their summer time but it's generally not used - the adjustment is assumed. We think of it differently because GMT is the reference (ignoring this newfangled French UTC crap). "Greenwich Mean Time - the only time worth spending time on." as the late Kenny Everett used to say.
Thus when someone in Malta gets a meeting request for 11:00 CET he thinks "Ah, that's my local time [adjusted for daylight saving], not the sender's time in the UK." whereas when someone in the UK gets a meeting request for 11:00 GMT he thinks "So not BST then, I'll have to add an hour.".
In other words it's us that's the problem, :-) although if the client makes it clear that it's showing a timezone rather than a time it would help. In RFC 2445 and 5445 (iCalendar format) an event includes a timezone definition with rules for both STANDARD and DAYLIGHT variants. It's down to the client to interpret that and display the meeting time appropriately if required.
Maybe it would help avoid the ambiguity if the UK moved to Western European Time? Although right now that would highlight another Outlook problem because though I see that Outlook interprets my location in Malta as UTC+1 and sets the TZOFFSETs correctly in the iCalendar field, it incorrectly gives the timezone as Western European Time rather than Central. Sheesh, how difficult can it be?
Confused? This is a good example of where something wasn't fundamentally designed right in the first place and attempts to fix it just introduced more problems.
Microsoft could just call it "UK local time" or some such rather than calling it GMT (or as it seems to be called in the attached icalendar file) "GMT Standard Time", which does not help either. We know GMT is a "standard".
ReplyDeleteI am glad the extra note is removed in later releases as it does indeed make it even clearer that they are talking of GMT without daylight adjustments (as you would expect when talking about GMT).
Of course, saying it is "us" that is the problem is, well, wrong. We invented time, so clearly it is everyone else that is wrong :-).
TBH I still do not understand why we have to have daylight savings time in the first place. But that is a whole other rant, especially when there are people out there that genuinely believe that changing the clocks changes how many "hours of daylight" we have in a day!
As well as having a 'UK' timezone rather than trying to claim we are in GMT with daylight savings, they could also resolve the ambiguity by putting the UTC offset in, so e.g. they'd say "11:00-12:00 (UK / UTC+1)" - there's never confusion about when UTC is, so it would be clear to everyone...
ReplyDeleteAgree about questioning the necessity for DST. Most of the Mediterranean countries go along with DST to stay in line with Europe yet operate different working/school hours as daylight and temperature change over the year. But in the UK we're stuck with this silly blue-collar 8am-4pm, white-collar 9am-5pm working hours ritual.
ReplyDeleteJJ,
ReplyDeleteOffice Professional Plus 2010 has been installed by default on BT PC builds since May, and can be upgraded to on existing Windows 7 installations. Office Professional 2010 was previously available as an upgrade.
The terminology issue that JJ mentions seems like nonsense to me. Firstly, lots of places *do* distinguish between standard and daylight time. Throughout the US they have EST/EDT, CST/SDT, MST/MDT, PST/PDT for example.
ReplyDeleteSecondly, the 'GMT' in this case, in the parentheses, *is* being used in the context that GMT/UTC are usually used for, as the base reference time zone. Not as the cosmetic name of the time zone. It's even more obvious when you see a meeting that's defined in some other time zone:
When: Monday, August 01, 2011 10:00 AM-11:00 AM (UTC-08:00) Pacific Time (US & Canada).
That's just *wrong*. It's certainly not just us. This meeting was actually at 10am (UTC-7).
There is no excuse for this kind of brokenness. But if you use Microsoft products, you get this level of kwality. What do you expect?
The brokenness isn't Microsoft's fault in this case. Take a look at RFC5445. You'd think they'd copy the *nix way of handling timezones but that would be too obvious.
ReplyDeleteI don't follow that at all "Basic Forward Error Correction (FEC) Schemes".
ReplyDeleteAnyway, regardless, stating a time is GMT when it is not, or a time is UTC-08:00 when it is not, is plain wrong. I had no idea it was that broken even outside the UK.
What kind of nonsense is this? The brokenness is *entirely* Microsoft's fault.
ReplyDeleteIf you look at the RFC5545 iCal attachment in the offending invites from Exchange, they're actually correct in everything but the "cosmetic" TZNAME field, which contains idiocies like "GMT Daylight Time".
What we're discussing here has nothing to do with that.
(Yes, it would be nice if RFC5545 had mandated the Olson database or if Microsoft had had the wit to use it, but that's irrelevant.)
Where do you see "GMT Daylight Time"? I've tried Exchange 2007 and 2010 and both say "GMT Standard Time" (yes, wrong anyway I know). Point is, the RFC has one time zone, in two variants, not a time zone for daylight saving and one for not.
ReplyDeleteAnyone with Sky, is it currently promoting programme times in CET or CEST?
RFC5545 has one VTIMEZONE, with *multiple* STANDARD and DAYLIGHT variants. And you get to give a TZNAME for each. See the example showing rules for New York since 1967, in §3.6.5.
ReplyDeleteI haven't seen 'GMT Daylight Time' recently; perhaps that's older versions of Windows/Exchange. Looking at EWS responses (which map fairly closely to a VTIMEZONE except it makes the mistake of assuming there can be only two), I see this kind of thing:
<t:MeetingTimeZone TimeZoneName="Pacific Standard Time">
<t:BaseOffset>PT480M</t:BaseOffset>
<t:Standard TimeZoneName="Pacific Standard Time">
<t:Offset>PT0M</t:Offset>
<t:RelativeYearlyRecurrence>
<t:DaysOfWeek>Sunday</t:DaysOfWeek>
<t:DayOfWeekIndex>First</t:DayOfWeekIndex>
<t:Month>November</t:Month>
</t:RelativeYearlyRecurrence>
<t:Time>02:00:00</t:Time>
</t:Standard>
<t:Daylight TimeZoneName="Pacific Daylight Time">
<t:Offset>-PT60M</t:Offset>
<t:RelativeYearlyRecurrence>
<t:DaysOfWeek>Sunday</t:DaysOfWeek>
<t:DayOfWeekIndex>Second</t:DayOfWeekIndex>
<t:Month>March</t:Month>
</t:RelativeYearlyRecurrence>
<t:Time>02:00:00</t:Time>
</t:Daylight>
</t:MeetingTimeZone>
And for UK meetings I see this:
<t:MeetingTimeZone TimeZoneName="(UTC) Dublin, Edinburgh, Lisbon, London">
<t:BaseOffset>PT0M</t:BaseOffset>
<t:Standard TimeZoneName="(UTC) Dublin, Edinburgh, Lisbon, London">
<t:Offset>PT0M</t:Offset>
<t:RelativeYearlyRecurrence>
<t:DaysOfWeek>Sunday</t:DaysOfWeek>
<t:DayOfWeekIndex>Last</t:DayOfWeekIndex>
<t:Month>October</t:Month>
</t:RelativeYearlyRecurrence>
<t:Time>02:00:00</t:Time>
</t:Standard>
<t:Daylight TimeZoneName="(UTC) Dublin, Edinburgh, Lisbon, London">
<t:Offset>-PT60M</t:Offset>
<t:RelativeYearlyRecurrence>
<t:DaysOfWeek>Sunday</t:DaysOfWeek>
<t:DayOfWeekIndex>Last</t:DayOfWeekIndex>
<t:Month>March</t:Month>
</t:RelativeYearlyRecurrence>
<t:Time>01:00:00</t:Time>
</t:Daylight>
</t:MeetingTimeZone>
Note: it has clearly stated "UTC" specifically for the *daylight* time. It has similar brokenness for Jerusalem, where it says UTC+02:00 for *both* the standard and daylight zones, despite actually giving the correct offsets in the data structure.
<t:MeetingTimeZone TimeZoneName="(UTC+02:00) Jerusalem">
<t:BaseOffset>-PT120M</t:BaseOffset>
<t:Standard TimeZoneName="(UTC+02:00) Jerusalem">
<t:Offset>PT0M</t:Offset>
<t:RelativeYearlyRecurrence>
<t:DaysOfWeek>Sunday</t:DaysOfWeek>
<t:DayOfWeekIndex>Second</t:DayOfWeekIndex>
<t:Month>September</t:Month>
</t:RelativeYearlyRecurrence>
<t:Time>02:00:00</t:Time>
</t:Standard>
<t:Daylight TimeZoneName="(UTC+02:00) Jerusalem">
<t:Offset>-PT60M</t:Offset>
<t:RelativeYearlyRecurrence>
<t:DaysOfWeek>Friday</t:DaysOfWeek>
<t:DayOfWeekIndex>Last</t:DayOfWeekIndex>
<t:Month>March</t:Month>
</t:RelativeYearlyRecurrence>
<t:Time>02:00:00</t:Time>
</t:Daylight>
</t:MeetingTimeZone>
Like most people not using outlook we see some text which is stating wrong things, and an "attachment" which means nothing.
ReplyDeleteThe text being wrong is the big issue for me.
However, yes, interesting that the attachment is also wrong in what it states
RevK, that attachment is actually mostly *correct* in what it states. If you base64-decode it, it's readable as plain text. And I don't think it's fair to say "most people not using Outlook"; this is a text/calendar attachment conforming to RFC5545. GMail users for example should see it quite correctly as a meeting invite, with the correct times. Likewise Evolution users.
ReplyDeleteThe contents will look something like this:
BEGIN:VCALENDAR
METHOD:REQUEST
PRODID:Microsoft Exchange Server 2007
VERSION:2.0
BEGIN:VTIMEZONE
TZID:GMT Standard Time
BEGIN:STANDARD
DTSTART:16010101T020000
TZOFFSETFROM:+0100
TZOFFSETTO:+0000
RRULE:FREQ=YEARLY;INTERVAL=1;BYDAY=-1SU;BYMONTH=10
END:STANDARD
BEGIN:DAYLIGHT
DTSTART:16010101T010000
TZOFFSETFROM:+0000
TZOFFSETTO:+0100
RRULE:FREQ=YEARLY;INTERVAL=1;BYDAY=-1SU;BYMONTH=3
END:DAYLIGHT
END:VTIMEZONE
BEGIN:VEVENT
DTSTART;TZID=GMT Standard Time:20110811T093000
DTEND;TZID=GMT Standard Time:20110811T100000
...
You can see it specifies the precise DST rules for the zone it calls "GMT Standard Time", and then defines the meeting in that timezone — thus there is no ambiguity. The brokenness is merely cosmetic, because it shouldn't be calling that timezone "GMT".
It looks like JJ is right that they don't include the doubly-nonsensical "GMT Daylight Time" TZNAME any more. They don't include a TZNAME in *either* the STANDARD or DAYLIGHT components.
I really do not give shit what most people use - the text of the email is quite simply WRONG - there is no denying that. Anyone not using something capable of reading the attachment will see the wrong meeting time. As others have quoted, quite often the text in the attachment is wrong too.
ReplyDeleteYou're absolutely right. The text of the email is completely wrong. And their stupid "does not reflect daylight saving time adjustments" addendum is just saying "our code is broken but we can't fix it so we just tell you it's broken". Microsoft at their stupidest and least professional, in my opinion.
ReplyDeleteI have no interest in what most people use either; I was only responding to that because you brought it up.
The cosmetic *text* in the attachment is often misleading, as I showed — but the actual *data* in the RFC-compliant attachment will give the correct time.
Yes, sorry if I was a bit too ranty there... I have learned it is even more broken that I thought though, as I had never seen the problems in other timezones before - so thanks all for the comments on this.
ReplyDelete