Hi Yongsheng,
There's in fact a bug in the way the autoenddate case was handled. To
detect end-of-day, it converted the timestamp into local time, and
when it saw 23:59:59 this was converted to beginning of next day - but
I forgot to write back the time context, so it came out as UTC 0:00
instead of localtime 0:00.
See the following patch, I'll commit it to indefero master soon.
From 432d434d0f71dad2d33a223d53acc022e097ad15 Mon Sep 17 00:00:00 2001
From: Lukas Zeller <[email protected]>
Date: Wed, 12 Aug 2009 11:54:05 +0200
Subject: [PATCH] mimedirprofile: autoenddate 23:59:59 detection bug
fixed
to detect 23:59:59, the timestamp was converted to item time
zone (which is usually system local time). When detecting
23:59:59, the timestamp is modified to represent 0:00
of the next day.
But when writing back the timestamp into the field
(usually DTEND), the now changed time zone information
was not written along with it.
So for vCalendar 1.0 that use UTC representation of
local time 23:59:59, the value written back to
DTEND was UTC 0:00 instead of localtime 0:00.
For vCalendar 1.0 records which use floating
(i.e. localtime) representation of DTEND for
allday events the code worked because no
time zone conversion took place.
---
sysync/mimedirprofile.cpp | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/sysync/mimedirprofile.cpp b/sysync/mimedirprofile.cpp
index ba3df65..2dbabc5 100644
--- a/sysync/mimedirprofile.cpp
+++ b/sysync/mimedirprofile.cpp
@@ -3162,8 +3162,8 @@ bool TMimeDirProfileHandler::MIMEStringToField(
lineartime_t ts = tsFldP-
>getTimestampAs(fItemTimeContext,&tctx); // get in item context or
floating
lineartime_t ts0 = lineartime2dateonlyTime(ts);
if (ts0!=ts && AlldayCount(ts0,ts)>0) { // only if not
already a 0:00
- // this is a 23:59 type end-of-day, convert it to
midnight of next day
- tsFldP->setTimestamp(lineartime2dateonlyTime(ts)
+linearDateToTimeFactor);
+ // this is a 23:59 type end-of-day, convert it to
midnight of next day (AND adjust time context, in case it is now
different from original)
+ tsFldP-
>setTimestampAndContext(lineartime2dateonlyTime(ts)
+linearDateToTimeFactor,tctx);
}
}
}
--
1.6.1.2
On Aug 12, 2009, at 5:17 , Zhu, Yongsheng wrote:
However, I'm still a bit fuzzy about how autoenddate interacts with
the
"detect alldays in vCalendar 1.0 (0:00-0:00 or 23:59 localtime)"
part of
VCALENDAR_INCOMING_SCRIPT. Can someone walk me through the sequence
of
conversions that happen when applying autoenddate to the mobical.net
example DTSTART/END and why MAKEALLDAY() then fails?
Let me give you an example of this:
Here is the sub-part of a vcalendar1.0 file from a server:
DTSTART:20060406T060000Z
DTEND:20060407T055959Z
Synthesis interprets as:
- 17 : timestamp DTSTART [ 0, 0, 0] :
2006-04-06T06:00:00Z (TZ: UTC)
- 18 : timestamp DTEND [ 0, 0, 0] :
2006-04-07T00:00:00Z (TZ: UTC)
My client timezone is '-6:00' hours of UTC. so 'DTEND' is checked
whether it is the last time of one day
with client timezone and then converted if yes. The original
calendar was a 'all-day-event', however,
after interpretation, the event was not a 'all-day-event'. This
prevents our incoming scripts judge it as
a 'all-day-event'.
Best Regards,
Lukas Zeller ([email protected])
-
Synthesis AG, SyncML Solutions & Sustainable Software Concepts
[email protected], http://www.synthesis.ch
_______________________________________________
os-libsynthesis mailing list
[email protected]
http://lists.synthesis.ch/mailman/listinfo/os-libsynthesis
