[Design] [Dogfood] Default TZ and interop

[Philippe Bossut]

Hi,

Jeffrey Harris wrote:
>> I think this problem could be interpreted differently: the invite
>> specified a specific time and timezone (say, 22:00Z), but we stored the
>> event using a floating timezone (22:00 floating). As I interpret the
>> design intention, we should instead have preserved the event's timezone
>> as GMT (causing it to appear in the 2:00PM spot, but labeled "10:00 PM
>> GMT").

But that only works if Chandler "knows" that PST is the time zone of the 
user. May be that is the case but that was unknown to me. I thought that 
the default was that the whole TZ arithmetic was simply bypassed. OK, if 
this is not the case, then I'm fine with the current default, assuming 
we do the correct TZ arithmetic.

>>  (I think this design could be improved upon: we could decide that
>> GMT is less friendly, and convert events to the local system's timezone
>> on import if their timezone is GMT, whether the timezone preference is
>> on or off.)
>>     
>
> To be clear, in no-timezone mode we *should* be preserving timezones,
> we're just not displaying them.
>
> We can't really safely change the timezones of items we share, and our
> code base currently doesn't distinguish between sharing and importing,
> so converting the timezone on import is a little problematic.  But
> rendering UTC differently is still reasonable.
>   

What about other timezones? Can we receive events expressed in something 
else than UTC? If yes, will they display at the wrong time under your 
proposal? (i.e. will I miss my call?)

Cheers,
- Philippe