Topics

moderated UTC values in Calendar time zone selection #suggestion #bug


Kenny Paul
 

Yes, I believe this to be both a suggested and a bug...
Our global community is adopting true UTC for meeting times which does not change with the seasons . 
I just set up a reoccurring meeting and the results were not what I expected.  As such, an investigation ensued ;-)  

There are three options for UTC in the picklist for setting up a meeting:


The top choice at first glance is what many associate with True UTC, but it isn't. It reflects the UK which moves to daylight savings (UTC +1) starting on Mar 31, 2019 
Morocco adopted Centeral European Time (UTC +1) year round with no daylight savings beginning this year
The Monrovia, Reykajvik option reflects countries that do not change. i.e UTC == UTC year round

As a test I set up 3 09:00 meetings for the above timezones in the cal for today and April 1, 2019 when the UK . (no April Fools joke here)
Note that I'm in the Pacific time zone and we have already switched, to daylight savings (UTC -7) so A that explains the that does not come into play here.
 

So there seems to be an error reflected times for Casablanca (UTC +1 year round). (bug)
The UK meeting on April 1 should be an hour later (UTC +1) rather than earlier  (bug)
To pick UTC someone needs to to that Iceland == UTC

Feature request is to have  just a plain old UTC with no other city qualifiers to avoid confusion.

Thanks!
--
Kenny Paul, Technical Program Manager for ONAP
The Linux Foundation
Pacific Time Zone


Dave Sergeant
 

Actually for us in the UK groups.io does exactly what we want,
displaying local time for calendar events all the year round. Unlike
Yahoogroups when we had to select the Reykajvik option to prevent it
screwing up times during the summer months.

Bear in mind if Europe approves the proposal currently going through
the European parliament the annual change will be abolished from next
year with individual countries choosing either to stay on summer time
or winter time throughout the year. Looks like chaos is on the way, and
it seems even if we leave the EU we will still implement it in the UK.

Dave

On 11 Mar 2019 at 8:19, Kenny Paul wrote:

Yes, I believe this to be both a suggested and a bug...
Our global community is adopting true UTC for meeting times which does
not change with the seasons . 

http://davesergeant.com


Kenny Paul
 

Sorry for the inadvertent all'd paste below my sig in the original message

On Mon, Mar 11, 2019 at 08:30 AM, Dave Sergeant wrote:
Actually for us in the UK groups.io does exactly what we want,
displaying local time for calendar events all the year round.
Understood.  If the meeting is set for 09:00 to London from the picklist and you want the meeting to continue at 09:00 London time after the time change, it will do everything correctly.
Our desire is not to rely on any not any local time zones for meeting creation, but instead to have true UTC be the anchor because it never changes even when other clocks may.  

For example my 14:00 UTC anchored meeting last week was 06:00 my time.  This week that same 14:00 UTC anchored meeting occurs at 07:00 in my time zone because the US flipped to DST yesterday. That is the behavior we want to see. In November locally it will go back to a 06:00 meeting time for me.  Gio cal does the correct thing --IF-- UTC Reykajvik  is selected from the picklst when the meeting is created.

With regards to the feature request, my fear is that members of the community will unwittingly select UTC London rather than Reykajvik as I initially did.  I'm spreading the word, but here again I'm looking for something "idiot" proof with regards to selecting UTC.

Hope that helps to clarify.
--
Kenny Paul, Technical Program Manager for ONAP
The Linux Foundation
Pacific Time Zone


 

Hi Kenny,

Steps to the mike. "This is more of a comment than a question, but I HATE DAYLIGHT SAVINGS TIME". Ahem.


On Mon, Mar 11, 2019 at 8:19 AM Kenny Paul <kpaul@...> wrote:

As a test I set up 3 09:00 meetings for the above timezones in the cal for today and April 1, 2019 when the UK . (no April Fools joke here)
Note that I'm in the Pacific time zone and we have already switched, to daylight savings (UTC -7) so A that explains the that does not come into play here.
 

So there seems to be an error reflected times for Casablanca (UTC +1 year round). (bug)
The UK meeting on April 1 should be an hour later (UTC +1) rather than earlier  (bug)
To pick UTC someone needs to to that Iceland == UTC

Dealing with timezones confuses me. Like really confuses me. There, I admitted it. That said, I just spent a bunch of time looking at this, and I think (think!) that our calendar is doing the right thing wrt to London. In London, if an event is at 9am on March 30th, we want it to be at 9am on April 1, right? But 9am on April 1 occurs one hour earlier to an observer whose wall clock didn't just spring forward an hour, including us here in the Pacific. So I think the 1am on April 1 is correct. I was able to duplicate this with GCal as well.

I have added a specific UTC entry when selecting a timezone. I've fixed the (UTC) entry for Casablanca when selecting the timezone.

If you have any suggestions for how to improve the timezone selection, I'm all ears. I do need to regen it on a regular basis to update the UTC+/- numbers, but as you point out, that doesn't really show which currently UTC-equivalent timezones have different daylight savings settings.

Thanks,
Mark 

 


Kenny Paul
 

On Mon, Mar 11, 2019 at 09:06 PM, Mark Fletcher wrote:
Hi Kenny,
 
Steps to the mike. "This is more of a comment than a question, but I HATE DAYLIGHT SAVINGS TIME". Ahem.
I concur. 
<snip>
 
I have added a specific UTC entry when selecting a timezone. I've fixed the (UTC) entry for Casablanca when selecting the timezone.
I actually just saw that a half hour ago while recording a "How-to"!   T H A N K   Y O U !  :-D
 
If you have any suggestions for how to improve the timezone selection, I'm all ears. I do need to regen it on a regular basis to update the UTC+/- numbers, but as you point out, that doesn't really show which currently UTC-equivalent timezones have different daylight savings settings.
My only other suggestion at the moment is to outlaw the practice of DST, but my plot for world domination has not progressed far enough to facilitate that yet. ;-)

--
Kenny Paul, Technical Program Manager for ONAP
The Linux Foundation
Pacific Time Zone


Andy Wedge
 

Hi Mark,

I'm not sure if this is related to recent changes in this area or whether it's been around for a while.

I have a calendar event running from 9/5/18 to 12/5/18 (4 full days) which shows as ending on 13/5/18 when I hover the mouse over the event:




When I edit the event though, it is shown as just 4 days:



Regards,
Andy


 

On Thu, Mar 14, 2019 at 3:27 AM Andy W <andy_wedge@...> wrote:

I have a calendar event running from 9/5/18 to 12/5/18 (4 full days) which shows as ending on 13/5/18 when I hover the mouse over the event:




When I edit the event though, it is shown as just 4 days:



This should be fixed now.

Thanks,
Mark 


Andy Wedge
 

On Fri, Mar 15, 2019 at 08:00 PM, Mark Fletcher wrote:
This should be fixed now.
Yes that looks good.

Thanks Mark.

Andy