Hi Philippe,

> 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.

We know the current timezone from the OS.  There increased risk that
non-timezone-users won't have this set properly, but I'm not sure what
we can do about that.

> 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?)

The idea of the no-timezone setting is that timezones are preserved, but
when you look on your calendar, everything outside the current timezone
(except UTC events) are displayed *at the wrong time*, as if the
timezone is metadata unrelated to what time the event takes place.

It seems perfectly clear to me that no one at OSAF will use this
setting, so it's inconvenient for us that the default out of the box
will be set this way.  But if we're going to have such a setting (for
people who live and work all in one timezone), we should probably have
it turned on by default, because presumably people who use timezones
know they care about them.

I wonder, though, if perhaps we should have a warning displayed the
first time a time-zoned event appears on your calendar, prompting you to
turn on timezones (or check a box to never ask me this again)?  That way
we advertise the feature in an only moderately intrusive way for people
who were expecting it to be turned on?

Sincerely,
Jeffrey
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

Open Source Applications Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design

Reply via email to