[horde] Problem kronolith

[R.J.Baart at Prompt.nl]

Amazing, I really think I have a huge influence.

The bug in Thunderbird seems to have been fixed this morning in the 
latest version of Thunderbird. It concerns Thunderbird Desktop Version 
148.0, released February 24, 2026. I haven't checked it yet, but the 
release notes say “fixed: iCal imports misread unknown time zones as 
GMT, creating events at wrong times.”

That's really fast.


Op 2026-02-25 om 11:02 schreef Ruud Baart:
> Thanks, I made a bug report in Bugzilla. Hope they find a solution.
>
> My (ugly) temporary work around for the moment is to make a progresql 
> cronjob that looks for null values in the kronolith_events table and 
> fill these with our timezone (Europe/Paris) and adjust the 
> modification time. With a sync of the calendar it should be fine for 
> the users.
>
>
> Op 2026-02-25 om 10:54 schreef Ralf Lang:
>> Hi Ruud,
>>
>> yes, I read it that way. Now telling Thunderbird to change is beyond 
>> me unfortunately. It's a wholly different beast I fear.
>>
>> Ruud Baart <r.j.baart at prompt.nl> schrieb am Di., 24. Feb. 2026, 15:40:
>>
>>     Thank you for this explanation.
>>
>>     Are you referring to this in the RFC 5545:
>>
>>     "The use of local time in a DATE-TIME or TIME value without the
>>     "TZID" property parameter is to be interpreted as floating time,
>>     regardless of the existence of "VTIMEZONE" calendar components in
>>     the iCalendar object."
>>
>>     This means: no timezone -> local time. And what local time is that
>>     depends on where you are. Correct?
>>
>>     It also means the Thunderbird calendar cache is faulty. It should
>>     not store "UTC" if timezone is empty. Correct?
>>
>>
>>
>>     Op 2026-02-24 om 15:22 schreef Ralf Lang:
>>>     Hi Ruud,
>>>
>>>     it's a good idea to increase data quality but it also introduces
>>>     some new problems.
>>>     |VEVENT| components without explicit |VTIMEZONE| entries are
>>>     valid in iCalendar (RFC 5545) and CalDAV, provided they follow
>>>     specific formatting rules for their time values.
>>>     We have to accept events, ics files, invitations etc from other
>>>     software products or from legacy data imports.
>>>
>>>     However we can define that we internally handle them with
>>>     timezone and always create/export them with timezone.
>>>     Which leads to a whole other category of fun whenever one
>>>     software product uses a timezone another doesn't know.
>>>
>>>     We will probably need to work on how exactly we achieve this
>>>     timezone compatibility the right way.
>>>
>>>
>>>     On Tue, Feb 24, 2026 at 3:13 PM Ruud Baart <r.j.baart at prompt.nl>
>>>     wrote:
>>>
>>>         Hi,
>>>
>>>         approximately 30,000 appointments are stored in the Horde
>>>         database,
>>>         roughly half of which do not have a time zone stored. That
>>>         works fine in
>>>         itself, but lately it has been causing problems in Thunderbird.
>>>
>>>             horde6=# select count(*) from kronolith_events where
>>>         event_timezone is null;
>>>               count
>>>             -------
>>>               13677
>>>             (1 row)
>>>
>>>             horde6=# select count(*) from kronolith_events where
>>>         event_timezone is not null;
>>>               count
>>>             -------
>>>               17499
>>>             (1 row)
>>>
>>>         If I have analyzed it correctly, this is because
>>>         Thunderbird's calendar
>>>         converts the null value to UTC in its cache (sqlite
>>>         databases). That is
>>>         not the correct value. So registering an event works fine,
>>>         but when you
>>>         reopen Thunderbird, the display is incorrect.
>>>
>>>         I would like to see Horde make a time zone mandatory when
>>>         storing
>>>         events. If the time zone is missing, it should take the time
>>>         zone from
>>>         the preferences, and if that is not possible, it should take
>>>         the system
>>>         time zone. I am not sure if my wish is already achievable
>>>         through the
>>>         configuration of Horde.
>>>