| Summary | Internal kolab time encoding |
| Queue | Horde Framework Packages |
| Queue Version | HEAD |
| Type | Bug |
| State | Not A Bug |
| Priority | 1. Low |
| Owners | wrobel (at) horde (dot) org |
| Requester | thomas.jarosch (at) intra2net (dot) com |
| Created | 04/10/2007 (6678 days ago) |
| Due | |
| Updated | 05/08/2007 (6650 days ago) |
| Assigned | 05/08/2007 (6650 days ago) |
| Resolved | 05/08/2007 (6650 days ago) |
| Github Issue Link | |
| Github Pull Request | |
| Milestone | |
| Patch | No |
Bug 1822was handled but I'm pretty confident thatthe fix applied there was indeed correct.
Kronolith uses the local timezone internally. And Kolab wishes to have
all day events remembered by their date only (no additional time
information). For an all day event that would occur today Kronolith
sets the start date to 0:00 08/05/2007 (local time). If the Kolab
driver would now use gmstrftime to generate a date string from this
timepoint, this would result in 2007-05-07 since 0:00 08/05/2007 local
time is 10:00 07/05/2007 GMT. I tested that whole day events are
actually misplaced a day to early if I apply the patch.
New Attachment: Kolab-en-de-code-date.patch
State ⇒ Assigned
change from gmstrftime() to strftime() has been discussed in
Bug 1822and was applied to CVS a while ago
(http://cvs.horde.org/diff.php?r1=1.34&r2=1.35&f=framework%2FKolab%2FKolab.php). I'll have to investigate if this was an incorrect
solution.
the Kolab module and not to Horde CVS.
Please have a look at the " Kolab-XML-time-functions.php" patch for
the "Kolab.php" file. It fixes the bug in Horde CVS. Just ignore the
part for Kolab/XML.php.
State ⇒ Not A Bug
the Kolab module and not to Horde CVS.
But you are certainly right and the conversion in the internal version
was flawed. I tried to correct this now and will keep you updated.
Assigned to Gunnar Wrobel
State ⇒ Assigned
gmmktime / gmstrftime function it behaves correctly.
with Horde_Date at all, btw.
gmmktime / gmstrftime function it behaves correctly.
a closer look.
New Attachment: Kolab-XML-time-functions.php
encode function, not the decode functon. Please try the new patch.
I've also updated the new XML.php to use the existing Kolab functions.
IMHO Kronolith internally uses localtime because only with the
gmmktime / gmstrftime function it behaves correctly.
I think the internal time encoding of the current Kolab code is
wrong. The dates stored in the XML source are UTC. The current
kronolith driver directly takes the output from
Kolab::decodeDateOrDateTime() which is produced by gmmktime.
modified but it has been checked in like that:
http://cvs.horde.org/co.php?r=1.16&f=framework%2FKolab%2FKolab.php
it together with kontact, the events start at the wrong time.
@Gunnar: Please check the patch with a real Kolab server without the
caching framework.
time format of a Kronolith_Event::start or end field? UTC or
localtime?
time format of a Kronolith_Event::start or end field? UTC or localtime?
Priority ⇒ 1. Low
State ⇒ Unconfirmed
New Attachment: kolab-fix-time-encoding.patch
Queue ⇒ Horde Framework Packages
Summary ⇒ Internal kolab time encoding
Type ⇒ Bug
I think the internal time encoding of the current Kolab code is wrong.
The dates stored in the XML source are UTC. The current kronolith
driver directly takes the output from Kolab::decodeDateOrDateTime()
which is produced by gmmktime.
You won't notice the bug if you only use kronolith, but when you use
it together with kontact, the events start at the wrong time.
@Gunnar: Please check the patch with a real Kolab server without the
caching framework.
Cheers,
Thomas