[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    Re: Replacement for KDateTime
From:       Dāvis Mosāns <davispuh () gmail ! com>
Date:       2015-08-10 10:31:50
Message-ID: CAOE4rSwTic1FwujnkAL20boqeoQKeTMcM4xO-qe8iWQw2C5nEw () mail ! gmail ! com
[Download RAW message or body]

2015-08-10 11:34 GMT+03:00 John Layt <john@layt.net>:
> On 9 August 2015 at 17:26, D=C4=81vis Mos=C4=81ns <davispuh@gmail.com> wr=
ote:
>>
>>
>> When I implement date/time related things I always use timestamps in
>> UTC everywhere
>> and when need to display to user or pass to some API then convert to
>> respective
>> format and timezone. Any other way makes it only more complicated.
>
>
> That works well when recording the time something occurred at, i.e. in th=
e
> past, but it just doesn't work for events scheduled in the future when th=
e
> time zone rules could change for both the source of the event and in any
> observers location. For example, if I'm in UTC+2 and I schedule a meeting
> every Monday  at 10am for the next 2 years, and the government changes th=
e
> time zone rule from UTC+2 to UTC+3, if I stored the event time in UTC the=
n
> my meeting has suddenly changed from 10am to 11am! If someone in the New
> York office phones in to the meeting, and their time zone rules change
> relative to UTC then they also get the wrong time. The only workable
> solution is to store the event in local time zone for the event location
> (unless they explicitly want UTC), and then convert it to the destination
> time zone at the last possible moment.
>

Indeed, I hadn't thought about this. Basically there's 2 types of time, one
is distinct fixed time point (I've worked only with these) and other
is human time
which doesn't really represent a distinct time because it might change rela=
tive
to UTC.
So if I set event to see solar eclipse I need to set it in UTC as
otherwise it will
be wrong when timezone or DST changes. But for meetings and other similar
things need it in human time as it doesn't matter that current 10am
actually isn't
that that same 10am when it was set. Also thinking about this I
realized that for
human time you don't need timezone but actually a place, location. Because
as you said timezone can change and it only depends on location. So to
convert time between different locations you need to get current timezones =
for
both locations. Timezone when event was set is useless because it might
have changed by now. So basically need to store time in either UTC or with
human time and location. Also location should be as precise as possible
because theoretically country can split and each part change to
different timezone.
[prev in list] [next in list] [prev in thread] [next in thread]