[Cosmo-dev] Re: [Cosmo] Login-related workflows update

[Jeffrey Harris]

Hi Jeremy,

> and yes, this implies adjusting  for daylight savings time, what it
> cannot tell you is whether you are in daylight savings time, which may
> be what you are alluding to, but for the purposes of setting a default
> calendar offset (as opposed to entering times) this may be entirely
> appropriate, especially if any sizable portion of users work in floating
> time.

I'm not really following you here.

If the user is working in floating time, offsets are mostly irrelevant.

If the user is actively using timezones, offset isn't enough, Cosmo
needs to extract the difference between, say, US Pacific and Canadian
Pacific, since our DST transitions are now divergent.  Figuring out what
timezone the user's machine is in is a non-trivial bit of work.

> As for rendering time, I assume the calendar events are returned in UTC
> with an offset if a timezone is assigned.

I hope that's not the case, that's certainly not the case in the desktop
client.  Even for non-recurring events, what timezone an event is in is
an important piece of semantic information, you can't just assign a UTC
time and an offset.  For recurring events especially, the timezone is
crucial.

Sincerely,
Jeffrey