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

* Your Email Address
* Spam protection	Enter the letters below: . ,. .. . __.. . \./ \ /\| \|(__ \|__\| \| \/ \|__\|.__)\| \|
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".
Attachment
Watch this ticket

Saved Queries