Storing UTC? There *is* a good case for local time!

Till Adam till.adam at kdab.com
Tue Dec 21 11:22:29 CET 2010


On Monday 20 December 2010 20:05:21 Georg C. F. Greve wrote:
> Hi all,
> 
> I am sure most of you know the following quote:
> 
>  	"For every complex problem, there is a solution that is
> 		simple, neat, and wrong."
> 									-- H. L. Mencken
> 
> I am afraid, this may apply to some extent to the idea to reduce complexity
> by storing everything in UTC. Allow me to try and explain the situation in
> a new way to help everyone get up to speed.

Point #3: the timezone information has useful additional semantics

As someone who travels reasonably frequently between timezones, I have the 
following use case, which is not sufficiently catered to by the existing UTC 
only solutions. If I am planing a week in, say, Chicago, I will be making 
appointments in local (Chicago) time, for that week. I'll chat with my 
customers there three weeks ahead of time, agreeing to meet for steak at 
Mortons at 7pm, or for coffee at my favorite Starbucks on Touhy Avenue at 9:30 
am. My client (Kontact) allows me to express that, but the appointment is 
stored as UTC only, in the Kolab folder. That means that next time I open up 
that calendar and appointment, it's shown to me in UTC time, which has no 
meaning in the context of me being in Chicago in the week I'm looking at. I 
would like to be able to say "I want to meet person A at 10, on the day where 
I'm meeting person A at 12", but I can't see the 12 o'clock, because it's 
somewhere in the middle of the night in UTC and even if I find it, by scrolling 
down, upon selecting it it does not show me when it will happen (in the 
context of the location's time). The existing workaround of showing more than 
one timezone axis in the agenda view, so I can mentally map that back to the 
target time is workable, but for quick, one day trips to Helsinki (which is an 
hour off), it's not very practical. So at least I, and my traveling colleagues, 
would really like to be able to store "8 am Chicago time next Monday" and be 
able to retrieve it from the Kolab storage with all of the information in 
there in another client.

This might be a fringe use case for the BSI, but in an international 
enterprise context, with conf calls frequently involving people from 3 or 4 
time zones, it's a reality we should accomodate.

</soap box>

Till

-- 
Till Adam | till.adam at kdab.com | Managing Director Germany
KDAB (Deutschland) GmbH & Co KG, a KDAB Group company
Tel. Germany +49-30-521325470, Sweden (HQ) +46-563-540090
KDAB - Qt Experts - Platform-independent software solutions




More information about the format mailing list