739290 - lightning should not have a time zone preference (but use system setting)

Status: NEW

(Calendar :: Preferences, defect)

Description

[Joe Drew (not getting mail)]

Lightning (perhaps calendar in general?) has a time zone preference in the Thunderbird preferences pane. This makes no sense—Lightning should do what Thunderbird does, and use the system's time zone.

Comment 1

[Philipp Kewisch [:Fallen][📱📆]]

While in general I agree that Lightning shouldn't need an extra preference, there are some complications. We need the recurrence rule component for the timezone. Unix zoneinfo doesn't provide this, afaik.


We could ship our own timezones and just use the name from the system zoneinfo. This will likely make it work for Linux/Mac. It may have been because of a testing profile, but I remember situations where my timezone was incorrectly detected.

Windows has a lot more problems. The timezones set in the system are a lot less than the olson timezones, so there needs to be some mapping between the OS timezone and the olson set of timezones and we definitely need to ship our own timezones here.

What we could do is add a checkbox to the timezone preferences (which is checked by default) to automatically detect the timezone. This would make our detection code run on each startup.

Going a step further, there are a few other bugs around that keep us from allowing to change the timezone without a restart. I've made them dependencies of this bug. Then some platform specific code needs to be created to detect the timezone change which is likely a WM_ message under windows and I'm not sure what it is under unix.

Comment 2

[Philipp Kewisch [:Fallen][📱📆]]

Also, there is a way to use the system zoneinfo, then this could break Asia/Jerusalem, where we currently hacked in using the full recurrence rules so their events are not offset by an hour, see bug 504299.

Comment 4

[Philipp Kewisch [:Fallen][📱📆]]

bug 439625 also suggests to show a dialog when the timezone has changed. This requires restartless timezone changes, but would also be an option if we still want to ship our own timezones.

Comment 5

[Joe Drew (not getting mail)]

(In reply to Philipp Kewisch [:Fallen] from comment #1)
> What we could do is add a checkbox to the timezone preferences (which is
> checked by default) to automatically detect the timezone. This would make
> our detection code run on each startup.

Not sure how it'll work, and as a first step on startup is obviously better than not at all, but supporting timezone changing at runtime (i.e., close laptop, take a plane trip, open laptop + timezone automatically changes) should be possible at some point in the future too. :)

Comment 6

[Magnus Melin [:mkmelin] (away, back Aug 4)]

Nowadays you can get the timezone from the Intl API, so perhaps this would be a fairly easy fix?

Intl.DateTimeFormat().resolvedOptions().timeZone

Comment 7

[Daniel Kahn Gillmor]

I just missed a meeting due to this confusion, as my sleep-deprived brain forgot that i had to manually fiddle with the Calendar Preferences to update them after the system time was adjusted.

So it would be great to see some progress on this.

The simplest possible improvement:

• if calendar.timezone.local is unset, then use the default system-specific value, as discovered at thunderbird startup.
• include "Use System Timezone" at the top of the dropdown list in the GUI preferences editor's Calendar tab; when it is selected, unset calendar.timezone.local (or use a checkbox/disabling option, as recommended by Phillip in comment #1

This wouldn't update in realtime, but it would help those of us who do correctly set the TZ and restart Thunderbird when traveling.

With this setup, people who prefer the current behavior can still keep it, while those of us whose machines maintain the system TZ correctly just need to restart Thunderbird.

From there, we can work on the tz detection updates

Comment 8

[Martin Schröder [:mschroeder]]

(In reply to Daniel Kahn Gillmor from comment #7)

• if calendar.timezone.local is unset, then use the default system-specific value, as discovered at thunderbird startup.

This has already been implemented in bug 1158733, and is available in current beta releases.

Comment 10

[Magnus Melin [:mkmelin] (away, back Aug 4)]

I think it's strictly not a duplicate.
Now that we do support system timezone, we should drop the possibility to set it manually. Outside of possibly troubleshooting scenarios, that doesn't seem very useful. It's only means it easy to get into the confused state, as comment 7 shows.
The dependencies of this bug needs to be looked at though.

Comment 11

[Andrei Hajdukewycz [:sancus]]

(In reply to Magnus Melin [:mkmelin] from comment #10)

I think it's strictly not a duplicate.
Now that we do support system timezone, we should drop the possibility to set it manually. Outside of possibly troubleshooting scenarios, that doesn't seem very useful. It's only means it easy to get into the confused state, as comment 7 shows.
The dependencies of this bug needs to be looked at though.

There are some cases(linux distros that don't support our method of getting the system time zone, I think) where the pref is still needed. But I agree we could hide it in most cases.

But, we should probably wait until the system timezone stuff has been in ESR for a while as people may be frustrated if it doesn't work and they have to manually enter things into calendar.timezone.local.