(In reply to comment #0)
> 1. Set the system clock in daylight saving time mode (+1 h)

How do you do that?

(In reply to comment #1)
> (In reply to comment #0)
> > 1. Set the system clock in daylight saving time mode (+1 h)
> 
> How do you do that?

http://en.wikipedia.org/wiki/Daylight_saving_time#How_it_works

   I was using automatic time updating based on the network time. At Saturday
the device had GMT+3, but at Sunday it had GMT+2, because the daylight saving
time had ended.

   You can reproduce the error by just changing the timezone. If you set the
system clock to GMT+3 and enter some new entries into the calendar, those
entries are shifted one hour when you set the system to GMT+2 afterwards. And
vice versa. The result is a total mess.

   The main problem is that daylight saving time is automatically changing that
setting twice a year!

   The entries in the calendar must not be relative to the UTC (GMT+0) and
timezone, but only the local time.

Comment 3 Andre Klapper 2009-10-27 16:18:59 UTC

> 1. Set the system clock in daylight saving time mode (+1 h)
How exactly and where?
> 2. Enter a new calendar entry (starting, say 8:00 AM)
> 3. Set the system clock in non-daylight saving time mode (+0 h)
How exactly and where?


Also quoting from the Spec:
"All calendar events, tasks and notes should be stored using UTC time (i.e.
device system time), so than when device's (user visible) local time is
changed, the events, notes and tasks automatically show changed time and date.
For example, devices local time is 17:00 GMT +2 (Helsinki/Finland). In
Calendar, event has been created for today 18:00. Timezone is changed to GMT+1
(Stockholm, Sweden) changing the local time to 16:00. When opening Calendar
again, the event shows in the UI at today 17:00."
   and
"daylight saving time (DST) should not have an effect to the calendar event
dates and time. For example, local time is winter DST, event shows in the UI
18:00. The DST changes automatically at spring equinox to summer DST. The event
shows in the UI at 18:00"

Comment 4 Andre Klapper 2009-10-27 16:20:32 UTC

Ah, now I see comment 2.
I don't really see a bug here, and a decision had to be made internally...

(In reply to comment #3)

> "All calendar events, tasks and notes should be stored using UTC time (i.e.
> device system time), so than when device's (user visible) local time is
> changed, the events, notes and tasks automatically show changed time and date.
> For example, devices local time is 17:00 GMT +2 (Helsinki/Finland). In
> Calendar, event has been created for today 18:00. Timezone is changed to GMT+1
> (Stockholm, Sweden) changing the local time to 16:00. When opening Calendar
> again, the event shows in the UI at today 17:00."

   This is not the actual problem here, but may be the root cause for it.

> "daylight saving time (DST) should not have an effect to the calendar event
> dates and time. For example, local time is winter DST, event shows in the UI
> 18:00. The DST changes automatically at spring equinox to summer DST. The event
> shows in the UI at 18:00"

   That is not what is happening - at least if the device is getting the time
from the network automatically. During the daylight saving time change last
Sunday all of my calendar entries jumped one hour backwards.

   When I studied my settings little further I found that in the manual
settings I had GMT+1 (Amsterdam), but the automatic settings had GMT+3
(Helsinki, DST) initially and GMT+2 afterwards (Helsinki). Naturally, I was not
able to see the manual GMT+1 setting, because the automatic settings hide the
manual settings in the control panel applet. Is it possible that the calendar
is somehow affected by the manual setting after all? (It should not, I think.)

(In reply to comment #3)
> Also quoting from the Spec:
> "All calendar events, tasks and notes should be stored using UTC time (i.e.
> device system time),

<OT>
When entering an event into the calendar, in many (most?) cases you want to
enter the event's local time, not the user's "home" time nor the user's local
time at the time of entry.

The only way to get this right is to record the intended timezone for each
event.  It can default to "local" or "home", but the user should be able to see
and change it easily.  I can hear the usual "the specs don't allow that because
we decided it's too confusing for the user" mantra coming, but wait: timezones
*are* recorded:

$ sqlite3  .calendar/calendardb
sqlite> select DateStart, DateEnd, Tzid, Summary from Components;
1255812000|1255815600|:Europe/London|Test event
1256230800|1256234400|:Etc/GMT-1|Dinner
1256238000|1256274000|:Etc/GMT-1|Party
1256716800|1256720400|:Europe/London|Another Test

(and in fact in local time), just invisibly to the user.  Ignore the bogus
Etc/GMT-1 issue for now (that's bug 5769) but also note that only the last one
is actually UTC and that is only by coincidence.

> so than when device's (user visible) local time is
> changed, the events, notes and tasks automatically show changed time and date.
> For example, devices local time is 17:00 GMT +2 (Helsinki/Finland). In
> Calendar, event has been created for today 18:00. Timezone is changed to GMT+1
> (Stockholm, Sweden) changing the local time to 16:00. When opening Calendar
> again, the event shows in the UI at today 17:00."

It depends on the event.  For something like a scheduled conference call with
people back in Helsinki the above is what you want.  Something like a
presentation or a return flight was probably entered with local (Stockholm)
time in the first place and should remain unchanged.  Finally something like
"13:00 Lunch" should probably stay at 13:00 local time whether you find
yourself in Helsinki, Stockholm or Sydney that day.
</OT>

> "daylight saving time (DST) should not have an effect to the calendar event
> dates and time. For example, local time is winter DST, event shows in the UI
> 18:00. The DST changes automatically at spring equinox to summer DST. The
> event shows in the UI at 18:00"

Ok, so at least according to the spec an event that changes time only because
of a DST change is a bug :-)

Now the only test I can think of for that is something like:

1. Set date to a date before the DST change (eg 2009-10-23).
2. Enter a calendar event for a later date (eg 2009-10-25 12:00-13:00)
3. Set date back to the correct one (2009-10-28).
4. Check the time of the event entered in step 2.

and I still see 12:00-13:00 after step 4.

I'm thinking this may have something to do with the automatic clock setting, ie
another case of the operator feeding the device a bogus timezone as with bug
5769, but I don't know how to test this before April :-|

Henrik: can you use sqlite3 as above to get a dump of one or two of the
affected events and post it here, along with the time(s) you originally entered
and the ones displayed now?

(In reply to comment #6)
> The only way to get this right is to record the intended timezone for each
> event.  It can default to "local" or "home", but the user should be able to see
> and change it easily. 

+1

> Now the only test I can think of for that is something like:
> 
> 1. Set date to a date before the DST change (eg 2009-10-23).
> 2. Enter a calendar event for a later date (eg 2009-10-25 12:00-13:00)
> 3. Set date back to the correct one (2009-10-28).
> 4. Check the time of the event entered in step 2.
> 
> and I still see 12:00-13:00 after step 4.

   Me too. I was not able to reproduce the bug that way.

> I'm thinking this may have something to do with the automatic clock setting, ie
> another case of the operator feeding the device a bogus timezone as with bug
> 5769, but I don't know how to test this before April :-|

   I suspect that too. My operator is Saunalahti / Elisa, Finland. Actually,
that sounds like an educated guess, and thus I will not reopen this if the
resolution is changed to WORKSFORME, for example (until next April ;).

> Henrik: can you use sqlite3 as above to get a dump of one or two of the
> affected events and post it here, along with the time(s) you originally entered
> and the ones displayed now?

   Unfortunately, no. I am using the calendar for my daily activities, and thus
went through all events correcting them manually (before the calendar comes too
packed and messed with the correct times and incorrect times - luckily I had
only few dozens of entries yet). So, no original incorrect entry is available
and I have no backup either.

Comment 8 Andre Klapper 2009-11-27 13:58:55 UTC

This has been fixed internally and is definitely fixed in 2.2009.48-x.
(Note that 2009 is the year and the number after is the week.)
This was fixed as a side effect so it's unclear when exactly it went in. :-P

Any public update released with or after this build version will include the
fix.
Please verify that the new version fixes the bug by marking this bug report as
VERIFIED after the public update has been released and if you have some time.

Comment 9 Andre Klapper 2010-01-14 12:29:54 UTC

The problem reported here should be fixed in the update released today for
public: The Maemo5 update version 2.2009.51-1 (also called "PR1.1" sometimes).
Please leave a comment if the problem is not fixed for you in this update
version.

Would be nice to retest/verifying this for the upcoming day light saving time
change this March ;)

Please re-open the bug - I have 3.2010.02-8.002 and yesterday my calendar
events changed time (actually - keep GMT-8, I believe). Yesterday (14/03) was a
switch to DST in USA.

Note: I finished upgrade to PR1.1.1 from PR1.1 day before (Saturday, 13/03
23h).

Comment 12 Andre Klapper 2010-03-15 21:09:37 UTC

egoshin: Can you please post your exact timezone data (city/area) on the N900?

Comment 13 Andre Klapper 2010-03-15 21:14:02 UTC

Looks like I'm going to handle the speicif case of GMT-8 in bug 9557. Please
comment there.

(In reply to comment #12)
> egoshin: Can you please post your exact timezone data (city/area) on the N900?
> 

Settings/Date and Time

24-hr clock - disabled
Update automatically - enabled
Time Zone GMT-7  (but should be GMT-8 in accordance with US post office: San
Francisco time == UTC - 8 plus DST difference)
Date Monday, March 15.2010
Time 1:07pm