Timezone issue—the clock, she is ticking…

[Bill Burcham]

Integration with Google Calendar necessitated producing UTC time (in
RFC 3339 format http://www.ietf.org/rfc/rfc3339.txt). Since Calagator
stores times in Portland time I added an ugly booger to the
event_helper that converts Portland time to UTC.

I researched timezone conversion a bit but it just seemed too tedious
and annoying. Instead I just hard-coded the routine to convert from
Pacific Daylight Time for now. So it'll work until we "Fall" back. And
then it'll work again in Spring '09.

A better fix would be to store all our DateTime's as UTC internally.
That would entail adjusting them every place we export or display. I
think most Web Services (like Google Calendar) operate on UTC so
things get easier there. Dunno if this'll cause extra annoyance for
iCal though.

On the web rendering side I recommend putting UTC's into the pages.
That way we don't have to know the user's UTC at all (and hence we
don't need profiles and logins). Instead we can convert the UTC's to
local-adjusted datetimes in the page with this JavaScript routine:

function LocalizeDateTime( e) {
if( e.firstChild) {
var d = new Date( Date.parse( e.firstChild.nodeValue));
e.firstChild.nodeValue = d.toLocaleDateString();
}
/* input fields don't have child content -- value is in "value" attr
*/
else if( e.value) {
var d = new Date( Date.parse( e.value))
e.value = d.toLocaleDateString();
}
}

Then we could flag pertinent elements with class 'date-time' for
instance and apply that function using whatever Calagator users to
apply JavaScript when the DOM changes.

[Bryan Stearns]

Hi Bill,

I like the idea of emitting UTC and letting the browser do the
conversion, but this tangles with the code I committed recently to
produce nicely-formatted date/time ranges with hCalendar markup; this
could be solved by reimplementing the formatting code to run on the
client side (though we could still do the hCalendar markup on the
server), but any clients that extract stuff from our hCalendar markup
would need to execute our Javascript, or the displayed labels for their
events wouldn't be in local time.

Also, we currently divvy up upcoming events into "today", "tomorrow",
"this week", etc on the home page; though it's unlikely that an event
would shift across a day boundary, we'd need to do that divvying on the
client side, too.

...Bryan

[Reid Beels]

This is a cool idea, but I think there are times when we're going to
be pushing data out to clients that don't support javascript, such as
feed readers and in ICS feeds. Storing dates as UTC makes sense to me,
but doing time-zone conversion of the client side seems like an
unnecessary point of possible failure. Calagator's initial focus is to
create a calendar for local events, so converting to a local time
before display doesn't bother me.

Reid

[Bill Burcham]

I think you're right on Reid, that it's perfectly OK, in fact more
than ok—important, for Calagator to display stuff in Portland time.
It's a Portland tech calendar, and as Bryan points out, the front page
divisions for "today", "tomorrow" wouldn't really make sense if we did
otherwise.

So what I'm hearing is:

1. agreement that we should store times in UTC in the database
2. we should display times on calagator.org in Portland Time
3. there are situations (e.g. today/tomorrow division on front page)
that necessitate converting UTC's to Portland Time on the server (so a
JavaScript-only approach won't work)

So that's cool. Now, reading Technoweenie it looks like Rails 2.1's
gonna have sane time zone support: http://weblog.techno-weenie.net/2008/2/6/timezone-awareness-in-rails
I think with that new support we'll be able to easily convert between
UTC and Portland Time (with DST correction) without the need to
install system-specific gems everywhere (unless you count Rails as a
system-specific gem).

As a bonus, Technoweenie suggests a hybrid approach, similar to the
code above that grabs the UA's timezone (thereby enabling us to
continue to avoid user profiles if we ever want to localize times in
future versions). Dig:

Cookie.set({tzoffset: (new Date()).getTimezoneOffset()});

So I'll go enter a ticket to remind us that this is gonna blow up in
the Fall and that we need to use Rails 2.1 time zone stuff and convert
to UTC's before then.