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

List:       kde-core-devel
Subject:    Re: Replacement for KDateTime
From:       John Layt <john () layt ! net>
Date:       2015-08-10 8:34:54
Message-ID: CAM1DM6k9LgXTFV=3=MgErm+MbCef8c9Uwta=dx00jEaak7zoQw () mail ! gmail ! com
[Download RAW message or body]

On 9 August 2015 at 17:26, D=C4=81vis Mos=C4=81ns <davispuh@gmail.com> wrot=
e:

>
> 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 the
past, but it just doesn't work for events scheduled in the future when the
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 the
time zone rule from UTC+2 to UTC+3, if I stored the event time in UTC then
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.

John.

[Attachment #3 (text/html)]

<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On 9 August 2015 at \
17:26, Dāvis Mosāns <span dir="ltr">&lt;<a href="mailto:davispuh@gmail.com" \
target="_blank">davispuh@gmail.com</a>&gt;</span> wrote:<br><blockquote \
class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex"><br> When I implement date/time related things I always use \
timestamps in<br> UTC everywhere<br>
and when need to display to user or pass to some API then convert to respective<br>
format and timezone. Any other way makes it only more complicated.<br>
</blockquote></div><br></div><div class="gmail_extra">That works well when recording \
the time something occurred at, i.e. in the past, but it just doesn&#39;t work for \
events scheduled in the future when the time zone rules could change for both the \
source of the event and in any observers location. For example, if I&#39;m in UTC+2 \
and I schedule a meeting every Monday   at 10am for the next 2 years, and the \
government changes the time zone rule from UTC+2 to UTC+3, if I stored the event time \
in UTC then 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.<br></div><div class="gmail_extra"><br></div><div \
class="gmail_extra">John.<br></div></div>



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