Time of events is shown in UTC, not local time

Bug #610416 reported by Rory McCann
This bug affects 14 people
Affects Status Importance Assigned to Milestone
LoCo Team Portal
Fix Released
Michael Hall

Bug Description

The events page of the loco directory shows times in UTC (i.e. +0000 timezone), example: http://loco.ubuntu.com/events/team/202/detail/ It should instead show times in local time for each loco. Many people coming to events are going to be coming from the local area, and will all be in the same timezone, so there is no need to include the timezone information. Secondly, timezones are confusing for many people, and showing event start times in UTC as opposed to local time forced people to do mental arithmetic when they see an event page. There is very little benefit from showing all times in UTC, and many drawbacks. Local time (for the LoCo) has more benefits and less drawbacks.

Related branches

Revision history for this message
Dave Walker (davewalker) wrote :

Do teams have multiple timezones?
Will an event span >1 timezones?
Should the event organizer specify the timezone for each event?

Changed in loco-directory:
status: New → Confirmed
Revision history for this message
Laura Czajkowski (czajkowski) wrote :

Well global events will span more than one timezone so when creating them it's possibly wise to pick UTC from timezone and only some people can create gloabl events.

With a LoCo it'd be nice to pick possibly UTC+x to select your timezone

Revision history for this message
dORSY (dorsyka) wrote :

I think that a real life event or direct LoCo events are better in local timezone. Online or events at multiple places are the ones that are better in UTC.

Revision history for this message
Michael Hall (mhall119) wrote :

The local time for an event should be determined by it's Venue, not it's Team.

Revision history for this message
Chris Johnston (cjohnston) wrote :

Yes, teams spread across multiple time zones.
A single event will probably not spread across multiple time zones, even by the same team.. (i.e. a team has a global jam event in one city, and another one in another city that are two different time zones, it is also two different events.
Yes, the organizer should specify the time zone (but this should actually be done by venue, just like the location and the languages can be set for a team, the time zone should be set for a venue.. a venues time zone is not going to change.)

Revision history for this message
Rory McCann (rorymcc) wrote :

I think there are use cases for both local & UTC (offline vs online being a good example). However I think local is a better default.

I suggest this:
(1) Each loco team has a timezone set. Note: Timezones are not "GMT+Xhrs", but things from tzdata like "Europe/Dublin", Otherwise you won't be able to deal with summer time/daylight savings time.
(1a) What LoCo teams cover more than 1 timezone? What should we do here? Have a list of timezones for this loco team (as opposed to just one)
(2) When adding an event there's a radio button under the time that says "( ) Local time ( ) UTC", with Local time being selected by default. Changing this radio button obviously means to change the timezone of the event. Note: A LoCo might be in summer time when an event is created, but it might have changed to non-sunmner time when the event occurs, so the UTC offset might change from when the event is created and when it takes place.
(3) Events stored in the database should probably be in some timezone independent format, like UTC, but this is less important.
(4) When viewing an event, if the creator entered it in UTC, show it in UTC (with the "UTC"/"+0000" suffix), if the creator entered it in local time show it in local time.

Luckily python has decent timezone support.

Revision history for this message
Chris Johnston (cjohnston) wrote :

Re: 1a) Rory, I know that Florida does, and I would suspect many other states do.

Changed in loco-directory:
importance: Undecided → Medium
Changed in loco-directory:
importance: Medium → Critical
Revision history for this message
Michael Hall (mhall119) wrote :

Found this, it may help.

Revision history for this message
Michael Hall (mhall119) wrote :
Revision history for this message
Daniel Holbach (dholbach) wrote :

I agree that this is an outstanding bug, but why is it Critical?


Changed in loco-directory:
importance: Critical → Medium
Revision history for this message
Laura Czajkowski (czajkowski) wrote :

Well my two cents is, it's important/critical as we are getting many teams to use the LD. A lot of people don't fully understand UTC so when they are creating events they're not fully taking this into account so they may not use it again. If they knew it was created in their own timezone it's one less barrier for users to shy away from using the LD

Revision history for this message
Daniel Holbach (dholbach) wrote :

I didn't say it wasn't important. I agree that it's a bug, but it's not of the "ok, let'd drop everything else we're doing and get working on it" importance.

Revision history for this message
James Tatum (jtatum) wrote :

It breaks the iCal feed

Revision history for this message
James Tatum (jtatum) wrote :

Chris Johnston correctly pointed out that my comment is not at all helpful, so I'll elaborate. This is what the 'iCal feed' link gives you on http://loco.ubuntu.com/events/team/273/detail/ical/:


The Z tacked on indicates correctly that the times above are in UTC. This makes perfect sense for someone tracking loco events across multiple time zones, but since you can't specify the correct time zone of the event, this event shows up as 4AM on my calendar.

So, yes, the Z could be removed to specify that the event is local time, but it isn't really the right solution since locos are all over the world and some locos span time zones.

Revision history for this message
Nathan Handler (nhandler) wrote :

Just as a note, comments on event pages also have a date displayed next to them. This date appears to be in UTC. Whatever decision is reached about time zones should be applied to the comments as well.

Revision history for this message
Darcy Casselman (dscassel) wrote :

Canada has 6 timezones.

Can you retrieve users' timezones from Launchpad? I should set events in my local time. I don't like having to do math when I'm scheduling events.

You could also set timezones on venues. Or infer the timezone from lat/long. The time could then be shown in the timezone for the venue.

Revision history for this message
Jessica Ledbetter (jledbetter) wrote :

I actually just ran into this when I was adding an event. It was a little confusing because it said local time but on the events listing it says "UTC."

I think we should allow someone to pick what timezone the event is. We could prepick it maybe? like Darcy suggested but still allow it to be picked. After user picks the timezone and date/time, we could display the converted UTC via Javascript (or such). Or a preview type deal that will show what it will look like once saved.

That might exist already in that django timezone code. I am new to python and django :)

Timezone: [Dropdown of GMT/UTC like launchpad's timezone picker]
Begins: [ Calendar bit you have ] [ time ] (_what this is in UTC_)
Ends: [ Calendar bit you have ] [ time ] (_what this is in UTC_)

Then store them all UTC in the DB.


Timezone: dropdown: value=GMT-5? US - Virginia *
Begins: 2010-10-20 16:00 EDT (2010-10-20 20:00 UTC) **
Ends: 2010-10-20 17:00 EDT (2010-10-20 21:00 UTC) **

* I picked GMT because that's what I'm familiar with but if we show the option's text that's understandable to the user like "US - Virginia" then it doesn't matter what the value is. Launchpad has that very understandable and we've used it to get to the loco.ubuntu.com so I'd stick with that :)

** Done via another dateformat on same value from db

On the events listing page maybe we can have "view in [timezone]". If we want to get really fancy, we could use the timezone from launchpad. :)

Michael Hall (mhall119)
Changed in loco-directory:
status: Confirmed → In Progress
assignee: nobody → Michael Hall (mhall119)
Changed in loco-directory:
status: In Progress → Fix Committed
milestone: none → 0.2.21
Changed in loco-directory:
status: Fix Committed → Fix Released
Revision history for this message
Craig Maloney (craig-decafbad) wrote :

This also affects the iCal Feed for the event:

http://loco.ubuntu.com/events/team/962/detail/ shows correctly, but http://loco.ubuntu.com/events/team/962/detail/ical/ still shows no offset.

Revision history for this message
Craig Maloney (craig-decafbad) wrote :

Addendum: The way that Google calendar is showing this event is from 3-6PM Eastern, but the iCal feed:


has the following:

CATEGORIES:Ubuntu Loco Team Event
DESCRIPTION:the MI Loco teams up with the CoffeeHouseCoders team to hold a
  weekly geek meeting at a local coffee shop. For event details and mapping
  see: http://coffeehousecode.appspot.com/locations/detroit.html
SUMMARY:UH:CHC (Ubuntu Hour/Coffee House Coders)

I'm not sure what's going on to make Google calendar not arrive at the right time, but it's preventing us from moving to the Ubuntu calendar exclusively.

Revision history for this message
Chris Johnston (cjohnston) wrote :

Craig, could you please separate the iCal problem into a separate bug.

Revision history for this message
A. Richard Miller (themillers) wrote :

I'm new to this problem, and consider it very important, perhaps critical, because:

1. It's telling readers that our meeting is tomorrow night, not tomorrow afternoon. Some will miss the meeting because of this error. See:

2. It told me to post in local time, but that apparently is not true.

3. It's where Ubuntu meets its users, and it's causing them to miss Ubuntu meetings!!
Why is that fix NOT urgent? How long has that been left unattended, and what is its message to those who rely upon calendar announcements?

Thanks for your consideration,
--A. Richard Miller (trying to invite folks to a Canonical presentation in Natick, tomorrow afternoon!)

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers