[Tickets #12483] Re: all-day events not marked as all-day in database

[noreply at bugs.horde.org]

DO NOT REPLY TO THIS MESSAGE. THIS EMAIL ADDRESS IS NOT MONITORED.

Ticket URL: http://bugs.horde.org/ticket/12483
------------------------------------------------------------------------------
  Ticket             | 12483
  Updated By         | skhorde at smail.inf.fh-bonn-rhein-sieg.de
  Summary            | all-day events not marked as all-day in database
  Queue              | Kronolith
  Version            | 4.1.2
  Type               | Bug
  State              | No Feedback
  Priority           | 1. Low
  Milestone          |
  Patch              |
  Owners             |
------------------------------------------------------------------------------


skhorde at smail.inf.fh-bonn-rhein-sieg.de (2013-08-09 06:40) wrote:

> 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".