[#12483] all-day events not marked as all-day in database
Summary all-day events not marked as all-day in database
Queue Kronolith
Queue Version Git master
Type Enhancement
State Accepted
Priority 1. Low
Requester skhorde@smail.inf.fh-bonn-rhein-sieg.de
Created 2013-07-21 (2582 days ago)
Updated 2014-08-20 (2187 days ago)
Assigned 2013-07-24 (2579 days ago)
Patch No

skhorde@smail.inf.fh-bonn-rhein-sieg.de 2013-07-21 14:48:40
If  you enter an all-day event in the Kronolith GUI, the entry in the 
DB is a 24 hour event, the field "event_allday" is zero.

This is a partial dump of all-day events sync'ed via 
Android/ActiveSync, Lightning/CalDAV and entered via GUI.

event_title     event_start     event_end     event_allday     event_timezone
L 11:00     2013-07-18 09:00:00     2013-07-18 10:00:00     0     
L allday     2013-07-18 00:00:00     2013-07-19 00:00:00     1
GUI allday     2013-07-18 00:00:00     2013-07-18 23:59:59     0     UTC
A allday     2013-07-18 00:00:00     2013-07-19 00:00:00     1
A 11:00     2013-07-18 09:00:00     2013-07-18 09:30:00     0

"L" is lightning/CalDAV, "A" is Android/ActiveSync, "GUI" event created
via GUI.

The GUI-event is not marked as "allday", but is a 24h-event from 0 through
23:59 UTC. That's why it spans days.

Michael Rubinsky <mrubinsk@horde.org> 2013-07-24 17:20:05
Are you explicitly setting the timezone to UTC when creating the 
event? What is your default timezone?

skhorde@smail.inf.fh-bonn-rhein-sieg.de 2013-08-09 06:40:54
> Are you explicitly setting the timezone to UTC when creating the 
> event? What is your default timezone?

Sorry I was away.

Hmm, two colleques and I tested the problem with 3 accounts, but now I 
cannot reproduce it. I really don't remember, if/why I selected "UTC" 
when creating the first test events. See below for the timezones.

Therefore I would like to change the bug report into a feature request:

Current behaviour: If one checks "All-day event", the time selection 
fields disappear from "From" and "to" dates. If one selects a 
timezone, that differs from "Default" or the user's H5-timezone, the 
all-day event is silently converted into a 24h event on submit.

Suggested behaviour #1: If one checks "All-day event", the time 
selection fields disappear from "From" and "to" dates, and timezone 
gets assigned to "Default". If one selects a timezone now, that 
differs from "Default", the time fields reappear with 00:00 and 24:00 
(or "from" 00:00 and "to" date+1 and 00:00). The "All-day event" check 
mark disappears.

So the user gets aware, that the event is not an all-day event, hence, 
that the new event won't appear in the "All day" box of the day view 
or other calendar front ends. So the user won't think to create an 
all-day event, but create a 24h event.

Alternative suggested behaviour #2: If one checks "All-day event", the 
time selection fields disappear from "From" and "to" dates, and the 
timezone gets assigned to "Default" and gets grey'ed out (inactive), 
so the timezone is not changable anymore. If one unchecks "All-day 
event", the time selection fields reappear and timezone gets active 

So the user cannot create a 24h event at all, if "all-day event" is checked.

Personally I'd stay with variant #2, as it looks like less support 
incidents to me. One can describe this behaviour simply as: "All-day 
events do not have no time zone. If you want to create a 24h event 
with timezone attached, uncheck all-day event."


The host system uses timezone CEST, the output of phpinfo() is:

date/time support         enabled
"Olson" Timezone Database Version         0.system
Timezone Database         internal
Default timezone         UTC

In Horde5 one colleque had "Default" as timezone - he probably is the 
only one, who got the 24h events by design, because Horde5 defaults to 
php's timezone UTC, I guess, but he probably selected Europe/Berlin - 
, the other one and I have "Europe/Berlin".

cne@ruhrverband.de 2014-08-20 10:41:14
Still see this "problem" on kronolith 4.1.5.