Summary | all-day events not marked as all-day in database |
Queue | Kronolith |
Queue Version | Git master |
Type | Enhancement |
State | Accepted |
Priority | 1. Low |
Owners | |
Requester | skhorde (at) smail (dot) inf (dot) fh-bonn-rhein-sieg (dot) de |
Created | 07/21/2013 (4315 days ago) |
Due | |
Updated | 08/20/2014 (3920 days ago) |
Assigned | 07/24/2013 (4312 days ago) |
Resolved | |
Milestone | |
Patch | No |
Priority ⇒ 1. Low
State ⇒ Accepted
event? What is your default timezone?
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 timeselection 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", thetime 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
again.
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 supportincidents 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".
Priority ⇒ 1. Low
State ⇒ Feedback
event? What is your default timezone?
Priority ⇒ 2. Medium
Type ⇒ Bug
Summary ⇒ all-day events not marked as all-day in database
Queue ⇒ Kronolith
Milestone ⇒
Patch ⇒ No
State ⇒ Unconfirmed
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
Europe/Berlin
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.