User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4a) Gecko/20030323 Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4a) Gecko/20030323 In Month View, on first mozilla startup, time of events are shown one hour later than they should be. The time is shown correctly in the dialog box if the event is edited. When any event is edited (no changes required) and saved, all times in Month View revert to their correct values. Reproducible: Always Steps to Reproduce: o Select month view in Calenadar o Create an event with a specific time (i.e. not a "lasts all day" one) o Verify time is correct in month view o quit mozilla, and restart (note: don't just close calendar and reopen; you need to quit mozilla entirely o Time is now incorrect in month view - it is 1 hour late. In fact all times are incorrect, in the same way. o Edit this event (or any other) (e.g. double-click on it) o Note the correct time appears in the event dialog box (although not on the month view) o Save the event without making any changes o All times are updated to correct time Actual Results: See above. Expected Results: See above.
I didn't seem able to reproduce this in Solaris/SPARC (after copying the calendar data file over). I've asked a colleague to try and reproduce under Linux/x86.
One other note: in the datafile, the event's times are correct (which might have been obvious).
Works fine for me on Linux with cvs 20030317
and irritatingly, I cannot reproduce using a new profile. So, there's something in my existing profile, or in my calendar datafile itself, that's provoking this bug. any ideas appreciated...
This sounds like a timezone bug. Calum, are you in a region with a timezone of GMT + 1?
That was the obvious thought, of course. No, we're currently on GMT, although ironically we switch to BST (GMT+1) on Sunday morning. A thought has occurred, in that I did copy my calendar file to another system, and edit there, copying backwards and forwards. However, both systems were (and are) running the same Linux kernel, with the same revs of the same Debian pkgs, and both have: diz $ file /usr/share/zoneinfo/localtime /usr/share/zoneinfo/localtime: symbolic link to /etc/localtime diz $ file /etc/localtime /etc/localtime: symbolic link to /usr/share/zoneinfo/Europe/London diz $ tzconfig Your current time zone is set to Europe/London Do you want to change that? [n]: Your time zone will not be changed finally, the obvious check is that both systems think they're currently in GMT, and both report the same time.
Further data point: as reported earlier, if I create a new profile, I cannot reproduce the problem in it. I just tried this again (same result) and then I coped my CalendarDataFile.ics from "default" into this new profile, and the problem went with it. So, it's down to something in my datafile, not in my profile. Here's an example entry from the datafile: BEGIN:VCALENDAR VERSION :2.0 PRODID :-//Mozilla.org/NONSGML Mozilla Calendar V1.0//EN BEGIN:VEVENT UID :930947060 SUMMARY :beers Fred? STATUS :TENTATIVE CLASS :PRIVATE DTSTART :20030318T180000 DTEND :20030318T230000 DTSTAMP :20030316T143546Z END:VEVENT END:VCALENDAR Despite the time for this event clearly being 1800, when I start calendar, this event appears with time set to 1900. As said before, if I do: o Double-click on empty day, to bring up new event dialog o Click OK the time on Fred's (unrelated) event gets set back to the correct value of 1800. What's more, all the other timed events get reset to their correct values too, apparently simultaneously. [These other events were also all one hour advanced over their correct time] I cannot see any TZ specifier in the event itself; is it supposed to be GMT?
Let's bring Mostafa in to have another calendar person look at this bug.
Created attachment 118631 [details] screenshot 1 Here's 2 attachments which illustrate the problem in a different way: look at 1.png and note the times of the events shown. Then look at 2.png, and note that the times have all moved on one hour. I took only one action between the 2 screenshots, and that was to enable a remote calendar "UK Holidays (Apple)" [which is http://ical.mac.com/ical/UK32Holidays.ics] On loading this calendar, all existing events had their times adjusted. This can't be right. Is there any way that adding a calendar can alter timezones etc? It may be an ironic coincidence that this remote calendar knows about the change to summer time we have coming this weekend...? I am working on a more solid method of reproducing in a fresh profile, which I will post in a moment.
I've been able to reproduce the problem using a fresh profile; I'd appreciate it if any other interested parties would give this a try... o Create an event with a specific time (i.e. not a "lasts all day" one). Add to default calendar. o Verify time is correct in month view # New step: o add this remote calendar: Tools->Subscribe to Remote Calendar. Location: http://ical.mac.com/ical/UK32Holidays.ics o Time for original event is suddenly incorrect in month view - it is 1 hour late. In fact all existing event times are now incorrect, in the same way. o quit mozilla, and restart. o times are still incorrect o Edit original event (or any other) (e.g. double-click on it) o Note the correct time appears in the event dialog box (although not on the month view) o Save the event without making any changes, i.e. just click OK. o All times are updated to correct time
Yup reproduced. I don't have to close mozilla down to get the times updated. Just click the test event and then do "ok" and all times are updated. Seems like importing the remote calendar screws times up ?
It's more subtle than just the presence of this remote calendar. I have now deleted all remote calendars, and their datafiles (using the UI, not manually), and restarted mozilla, yet the problem is still there. So, there's some state somewhere that's got messed up. Dave: would you please do a calendar delete (with files) for the remote calendar, and then verify the problem still exists (after a restart)?
Ok, i think i have sorted this issue out. If you *don't* have any TZ environment set, then the times are incorrect on restart of mozilla. If however i set TZ *before* starting mozilla, then all times are correct on a restart. This clearly only works on UNIX (Solaris, Linux, etc..) but i don't believe this can be done on Window$ ?
Confirmed; I did not have TZ set in my environment (and no reason why I should, if the system's TZ is set correctly, which it is). Setting TZ=GB before starting is a good workaround, thanks.
I'll take that back. Setting TZ makes the times correct at calendar startup. The instant an event is edited & saved, all the times jump forward one hour, and all are now wrong. Not a workaround after all.
Libical uses the TZ environment variable to do calculations when a datetime value is pure date( has no time set ) without properly setting it back causing jumps in times. This issue will be solved once we upgrade to the newer version of libical when it is out but for now we have tried to avoid encountering pure date values throughout the code. In this case it has slipped through our hands and the end date from the UK holidays files are becoming pure date values. The following change has fixed the problem: http://bonsai.mozilla.org/cvsview2.cgi?file=oeICalEventImpl.cpp&subdir=mozilla/calendar/libxpical&command=DIFF_FRAMESET&rev1=1.66&rev2=1.67 Calum MacKay: Your effort on pinpointing out the problem and finding a %100 reproducable case has been a huge help in tracking this down. Thanks a lot.
Status: NEW → RESOLVED
Last Resolved: 15 years ago
Resolution: --- → FIXED
Yup, looks good to me, just tried 20020403 and cannot reproduce the problem. Am I supposed to make this verified, or is that someone else's job? thanks very much Mostafa.
The bugspam monkeys have been set free and are feeding on Calendar :: General. Be afraid for your sanity!
QA Contact: gurganbl → general
You need to log in before you can comment on or make changes to this bug.