6.0.0-alpha10
5/14/25

Search Results: 410 of 573 [ <<First <Prev Next> Last>> ] [ Return to Search Results ]


[#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
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

History
08/20/2014 10:41:14 AM cne (at) ruhrverband (dot) de Comment #4 Reply to this comment
Still see this "problem" on kronolith 4.1.5.
08/09/2013 08:56:44 AM Jan Schneider Version ⇒ Git master
 
08/09/2013 08:52:14 AM Jan Schneider Type ⇒ Enhancement
Priority ⇒ 1. Low
State ⇒ Accepted
 
08/09/2013 06:40:54 AM skhorde (at) smail (dot) inf (dot) fh-bonn-rhein-sieg (dot) de Comment #3 Reply to this comment
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 
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 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".
08/08/2013 07:42:33 PM Michael Rubinsky State ⇒ No Feedback
 
07/24/2013 05:20:05 PM Michael Rubinsky Comment #2
Priority ⇒ 1. Low
State ⇒ Feedback
Reply to this comment
Are you explicitly setting the timezone to UTC when creating the 
event? What is your default timezone?
07/21/2013 02:48:40 PM skhorde (at) smail (dot) inf (dot) fh-bonn-rhein-sieg (dot) de Comment #1
Priority ⇒ 2. Medium
Type ⇒ Bug
Summary ⇒ all-day events not marked as all-day in database
Queue ⇒ Kronolith
Milestone ⇒
Patch ⇒ No
State ⇒ Unconfirmed
Reply to this comment
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     
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.

Saved Queries