times of events are displayed 1 hour later than they should be



16 years ago
12 years ago


(Reporter: Calum Mackay, Assigned: Mike Potter)




(2 attachments)



16 years ago
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.

Comment 1

16 years ago
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

Comment 2

16 years ago
One other note: in the datafile, the event's times are correct (which might have
been obvious).

Comment 3

16 years ago
Works fine for me on Linux with cvs 20030317

Comment 4

16 years ago
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

any ideas appreciated...

Comment 5

16 years ago
This sounds like a timezone bug. Calum, are you in a region with a timezone of
GMT + 1?

Comment 6

16 years ago
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.

Comment 7

16 years ago
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:

 :-//Mozilla.org/NONSGML Mozilla Calendar V1.0//EN
 :beers Fred?

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?

Comment 8

16 years ago
Let's bring Mostafa in to have another calendar person look at this bug.
URL: n/a

Comment 9

15 years ago
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

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.

Comment 10

15 years ago
Created attachment 118632 [details]
screenshot 2

Comment 11

15 years ago
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:

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 

Comment 12

15 years ago
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 ?

Comment 13

15 years ago
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)?

Comment 14

15 years ago
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$ ?

Comment 15

15 years ago
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.

Comment 16

15 years ago
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.

Comment 17

15 years ago
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:


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.
Last Resolved: 15 years ago
Resolution: --- → FIXED

Comment 18

15 years ago
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.