<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"><<a href="mailto:davispuh@gmail.com" target="_blank">davispuh@gmail.com</a>></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'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.<br></div><div class="gmail_extra"><br></div><div class="gmail_extra">John.<br></div></div>