301624 - Problem in special timezones - Calendar not creating calendars/events/tasks

Status: RESOLVED FIXED

(Calendar :: Internal Components, defect)

Description

[Sebastian Schwieger]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b4) Gecko/20050719 Firefox/1.0+
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b4) Gecko/20050720 Mozilla Sunbird/0.2+

I use Windows XP Professional German version 2002 SP2.
Having the Timezone set to GMT+01:00 (Amsterdam, Berlin,...) Calendar is not
able to create anything but UI is showing up. JS Console says:

Error: m has no properties
Source File: chrome://calendar/content/calendarUtils.js
Line: 181

When typing: (new Date()).toString()
the following is returned: Mon Jul 18 2005 10:00:41 GMT+0200 

Note: I figured out that behaviour is as expected whenever a timezone is
selected that returnes additional information in brackets like timezone
GMT+01:00 Bruessel, Kopenhagen, ... The returned String in the JS Console:

Mon Jul 18 2005 10:00:41 GMT+0200 (Romanische Sommerzeit)

I hope this helps,

Sebo


Reproducible: Always

Steps to Reproduce:
1.select timezone GMT+01:00 (Amsterdam, Berlin, ...)
2.start Sunbird
3.try to create calendar

Actual Results:  
nothing is created, also events and tasks cannot be created.

Expected Results:  
create calendar

Comment 1

[Joey Minta]

Attachment: guess TZs better

This patch takes a different approach to guessing the TZ of the computer.  It
checks the offset during both the winter and summer and then tries to match
that to something in the ical TZ database.  It doesn't usually gets things
right (It puts me in the Canary Islands instead of Dublin, but at least the
weather's better there.) but the errors usually have no practical differences. 
The advantage is that it doesn't require a TZ name at all, merely the offsets,
which can be grabbed by looking for + or - instead of using the .match()
function that seems to have caused this bug.

Comment 2

[Michiel van Leeuwen (email: mvl+moz@)]

I guess this patch is better then we have now. But for me, it guesses i'm in
'Africa/Ceuta'. Which really isn't true, but happen to use western european time.
I'm not sure if there is a better way. On my linux box, you could look at
/etc/sysconfig/clock but tha tmight be fedora or gnome specific. On the other
hand, it will increase the number of right guesses we make, even if it doesn't
help windows.
Another way to guess might be to look at the used locale. If i would use a dutch
build, it's likely that i am in the Europe/Amsterdam timezone. I think this
guess is easier to implement then the /etc/sysconfig/clock guess. Just add a
line to a sctringbundle.

Comment 3

[Joey Minta]

(In reply to comment #2)
calendarUtils.js reads:

 38 /*
 39  * Utility functions used by all calendar hosts (Sunbird, Lightning, etc.).
 40  * Functions in this file must _not_ depend on functions in any other files.
 41  */

Since Lightning uses this too, the stringbundles solution doesn't really seem 
feasible at this point, since lightning has no l10n whatsoever.  (Bug 298348 
doesn't block Lighting 0.1, so I don't want it to block Sunbird 0.3a1)  A third 
alterntive would be to put the previously used toString.match() in a try.  If 
we can grab a 3-letter tz name, then try searching through the TZs with that as 
a condition as well.  That would (hopefully) increase our correct guesses 
substantially.  (I'm also working on wiring up the actual TZ preferences 
dialog, so it should be easy for people to correct a wrong guess soon.)

Comment 4

[Michiel van Leeuwen (email: mvl+moz@)]

Maybe it can't depend on external things, that doesn't mean it can use them if
available. :)
Using the timezone name won't help in my case, as Africa/Ceute also uses CEST/EST.
(And that guess is wrong for >99% of the european users)

Comment 5

[Joey Minta]

Attachment: guess TZs better v2

OK, this time I'm using a combination of most of the options discussed.  If we
can find a string-bundle identifier, we check that first.  If we can get a
tz-short-name we also use that as a condition.	Since we're using short-names,
it now gets Dublin correct (IST in summer) and the string-bundle option should
get Amsterdam correct if you update the dutch locale.  This is a lot of work
just to guess the TZ, but I don't see a better way.

Comment 6

[Michiel van Leeuwen (email: mvl+moz@)]

Comment on attachment 190397 [details] [diff] [review]
guess TZs better v2

I guess this is as good as it gets with out hude timezone list. Having just one
entry for western europe (for example) would make guessing a lot easier.

I have some nits though: With this patch i get 2 js strict warnings. (icssrv,
daylightName and theTZ are not declared as var)
Also, you need to add a space before a (. (like in: +	 if(probableTZ))

Comment 7

[Joey Minta]

Attachment: guess TZs better v3

Sorry about that. v3 should fix the nits.

How do I enable js-strict warnings on Sunbird? 
(jsBranch.setBoolPref("options.strict",true) didn't work.)

Comment 8

[Michiel van Leeuwen (email: mvl+moz@)]

Comment on attachment 190618 [details] [diff] [review]
guess TZs better v3

>+    try {
>+        var mSummer = summerDate.match(/[^(]* ([^ ]*) \(([^)]+)\)/);
>+        var mWinter = winterDate.match(/[^(]* ([^ ]*) \(([^)]+)\)/);
>+        summerTZname = mSummer[2];
>+        winterTZname = mWinter[2];
>+    }
>+    catch(ex) { } //Oh well, one less piece of information...

I think a if(mSummer) check or something is better then a try block. Also, the
m prefix is generally for module vars, while mSummer here is very much local.
Please use a different var.

with those fixed, r=mvl

Comment 9

[Michael Jonsson]

How do I install a patch on a winxp???? 

Comment 10

[Joey Minta]

Attachment: guess TZs better v3.1

uses if for the string matching, and renamed the variable.

Comment 11

[Joey Minta]

Comment on attachment 191328 [details] [diff] [review]
guess TZs better v3.1

carrying over r+ from mvl

Comment 12

[Michiel van Leeuwen (email: mvl+moz@)]

patch checked in

Comment 13

[gekacheka]

Comment on attachment 191328 [details] [diff] [review]
guess TZs better v3.1

Nits:

1. Javascript dates are 0-based: 0 is january, 12 rolls over to january.  I
suspect you meant to get dates near the solstices, but it's off by a month.

2. July is only a summer month in the north, not in the southern hemisphere or
the tropics, so 
"summerDate" and "summerData" are misleading variable names.
Suggest "julyDate" and "julyData"; "januaryDate" and "januaryData".  (Or
juneDate/juneData and decemberDate/decemberData after you fix the dates to the
solstices.)

Comment 14

[Joey Minta]

*** Bug 301572 has been marked as a duplicate of this bug. ***