Closed Bug 300605 Opened 19 years ago Closed 16 years ago

Timezone should default to system timezone

Categories

(Calendar :: Internal Components, defect)

defect
Not set
normal

Tracking

(Not tracked)

VERIFIED FIXED

People

(Reporter: bugzilla.mozilla.org-3, Unassigned)

References

Details

Attachments

(2 files, 1 obsolete file)

The timezone in Options > My Timezone appearently defaults to "America/New_York".

It should default to the timezone used by the OS.
Is there a good way to find out what the current OS timezone is?  
(Not just the offset from GMT, because daylight/summer time changes differently
in different timezones with the same offset.).  

See discussion and patch in bug 301624 for current workaround.
This one should be closely related to Bug 164495.
Not sure if it's a duplicate though, but I guess it's possible =)
(In reply to comment #1)
> Is there a good way to find out what the current OS timezone is?  

I searched for it, and couldn't find it. Hence all the guessing in bug 301624.
Unfortunately, I do not have cycles to work on Calendar stuff these days (just as it's getting to the good part!), so I am a bad owner for these bugs.  To delete the tragically-large chunk of bugspam, search for gregorianabdication.
Assignee: shaver → nobody
> Is there a good way to find out what the current OS timezone is?  
On Windows, the timezone information is stored in HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\TimeZoneInformation

See http://www.911cd.net/forums/lofiversion/index.php/t2301.html for a few examples of what data is available for different timezones.

I guess with a bit of work it is possible to make a map that translates the combined values of StandardName and DaylightName into a city in that area (e.g. the combination of StandardName=="Eastern Standard Time" and DaylightName=="Eastern Daylight Time" maps to "America/New_York").

If the user has unchecked "Automatically adjust clock for daylight saving changes" in the Windows date/time dialog, it is reflected in the registry entry DisableAutoDaylightTimeSet. In this case, a fixed timezone (e.g. GMT+2) should be used (the zone Etc/GMT+2 exists on my Fedora box in /usr/share/zoneinfo/Etc/GMT+2 but it doesn't appear to be included in libical).
Hmm, appearently the contents of StandardName and DaylightName are localized in the different language editions of Windows. Perhaps DaylightStart and StandardStart can be used instead.
For Sunbird 0.3a2, when released, it would be helpful if we could achieve 1 of the following:

(a.) the timezone defaults to system (as requested this bug)
OR
(b.) guess timezone, ONLY if none yet defined (within Sunbird)
OR
(c.) manually set timezone, and retain for next session
  (without bug 304541, just support single entry field) 

This should not need to wait for:
 -  bug 304541 (timezone picker does nothing)
 -  bug 307557 (guess system timezone once per session)

As can be seen (in the attached testing, also posted to bug 328911) we need slightly better behaviour, as a minimum standard, for Sunbird 0.3a2 onwards
my system: win98se - so M$ does not issue patch for new dates for daylight savings time.  I am in EST [newyork] UTC-5

My workaround was to turn auto-adjust off in windows and just offset by 1 hour manually to UTC-4.

sunbird v0.5 adjusted for daylight savings time even though I had it turned off in the OS, so my entries were changed by an hour.  If I set an event to 06:00, sunbird would save it as 05:00

Since we are now well within the old daylight savings time period, I reset windows to UTC-5 and activated auto-adjust for DST.  This fixed the problem though i had to go back and adjust each entry item.

A lot of people have problem because of Bug 337191. If default timezone is equal to OS timezone it will help to resolve other bugs
Flags: wanted-calendar0.8?
Blocks: 400318
(In reply to comment #6)
> Hmm, appearently the contents of StandardName and DaylightName are localized in
> the different language editions of Windows.
The non-localized name can be found in HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Time Zones. These can be mapped to timezones from the Olson database.

http://support.microsoft.com/kb/933360
http://www.chronos-st.org/Windows-to-Olson.html
This patch looks for the system timezone name in various config files. On supported platforms this will usually find the user's specific timezone (continent+city) and not just some random conditent+city along the same longitude.

The code is inspired by <http://code.sixapart.com/svn/movabletype/trunk/extlib/DateTime/TimeZone/Local.pm>. 

I haven't ported the subroutine _from_etc_localtime. It is probably too expensive to iterate over all installed timezone files in /usr/share/zoneinfo (my box has 1740!), but I could look for a symlink (I don't have access to a machine that uses symlinks, though).

What do you think of this approach?
I'm not trying to be annoying here, but if you ported the code, how does that work with licenses? The license I found [1], says:
>  Restrictions on Use. You may not:
>    * Create derivative works based on the Beta Software;
Is your patch a derivative? (I really don't know licensing law, it scares me)

1: http://code.sixapart.com/svn/movabletype/trunk/LICENSE-BETA
My choice of the word "ported" was probably bad. I meant that my patch doesn't try to use /etc/localtime for determining the timezone, because this may be rather cumbersome. But if we want to do it, the subroutine _from_etc_localtime explains how to do it.

I didn't actually port the code. I just used it for inspiration on where to look for timezone settings. So no, there are definitely no licensing issues.
It would be good to have this in 0.8
Flags: wanted-calendar0.8? → wanted-calendar0.8+
No longer blocks: 400318
This is a proof of concept on how to look up the system timezone name in the Windows registry. This can be mapped to an Olson timezone using a table like this one: http://www.chronos-st.org/Windows-to-Olson.txt

Do you think this is a feasible solution?

For each Windows timezone there may be many Olson timezones. A Windows timezone is mapped to the Olson timezone representing the largest city in the Windows zone, i.e. my timezone isn't properly detected as Europe/Copenhagen but rather Europe/Berlin. This isn't a problem for dates in this century, but many years ago there may have been timezone differences between Copenhagen and Berlin.

The patch currently only supports a few timezones. To support all timezones, the mapping table should probably be included in a JS file of its own (do you agree?) that is generated automatically from the above mentioned TXT file by a Perl script or similar (or is that overkill?). I am not sure how this is usually done (and I hardly know any Perl).

The license terms for the mapping table looks rather liberal, but I don't know the procedure for including third-party content that isn't released under the Mozilla tri-license. Who should I ask about that? And is a simple table like that even protected by copyright? For a start we could ask the author whether he would release it under the Mozilla tri-license.
Attachment #289985 - Attachment is obsolete: true
Cc'ing Clint, because he is one of our timezone experts.
OS: Windows XP → All
Hardware: PC → All
Thanks for some good sleuthing!  The issues are well described by the article on the same site, so it was easy to redevelop the code:
http://www.chronos-st.org/Discovering%20the%20Local%20Time%20Zone--Why%20It's%20a%20Hard%20Problem.html

It was also easy to reproduce the data since each windows timezone description lists several cities, the largest of which is usually the ZoneInfo id city.  (Some pacific island zones required looking on the map a bit, though.)

The v6 patch for bug 328996 comment 26 incorporates these ideas.  It also checks to see whether the operating system timezone agrees with the calendar version of the ZoneInfo timezone; they may disagree if either or both are out of date, or if the user has disabled daylight saving time (a checkbox on windows).
gekachecka, does bug 328996 fix this issue also?
I'm not sure if this wasn't fixed by the fix for bug 328996. Reporter, could you perhaps test this again in a current nightly build?

If it isn't fixed, this probably won't make 0.8.
Flags: wanted-calendar0.8+ → wanted-calendar0.8-
Yes, it is fixed. Marking this WORKSFORME.
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → WORKSFORME
(In reply to comment #19)
> gekachecka, does bug 328996 fix this issue also?
> 
Yes, fixes merged into patch for bug 328996.  (patch known --> fixed)  (sorry for delay)
Resolution: WORKSFORME → FIXED
Target Milestone: --- → 0.8
Status: RESOLVED → VERIFIED
Flags: wanted-calendar0.8-
You need to log in before you can comment on or make changes to this bug.