How to save datetimes for future events

For future events, you expect to schedule a meeting &#x2F; appointment at [Local Time] on [Date] at [Location]. If a time change happens between now and the future event (e.g. daylight savings time), it doesn&#x27;t matter from the perspective of the meeting because you have a fixed time.<p>So, I would for future events record [Local Time], [Date], and [Location]. Then make sure I have a [Location] -&gt; [Time Zone] table. [Local Time] and [Date] would probably be combined into one field. The crux of the problem is shifting rules on time zone (and location is my time zone determinant), so recalculation for other time zones is going to have to be dynamic. Storing UTC or UTC offset doesn&#x27;t help the problem and actually creates a false solution.

This comes from mismatched expectations of what users are storing. Often they think, or assume without thinking, that they are storing a localized time. For ease of implementation, or just because the developer doesn&#x27;t know any better, we often store in absolute time (UTC) with an offset and call it done.<p>The problem is, nobody really thinks about this stuff. It&#x27;s easy to pick out an error case and say &quot;The users expect local (relative) time, we need to deliver that.&quot; That&#x27;s not always right. There are plenty of cases where the user really wants absolute time. Fro example, when scheduling an international meeting where the other side is dictating the time. When timing a broadcast from another country. Really, any time when you need to deal with events scheduled outside your local time, or have components (or people) that run on times that are not local to you.<p>It gets trickier. What if you are tracking that international event, and that locality changes their time rules? For example, what if I&#x27;m in the US, and I wanted to schedule a time to watch a sporting event in Chile, and I scheduled it before the changed mentioned in the article? Whether I store it as a local time or an absolute time, it&#x27;s wrong.<p>Really, you need three pieces of information. The UTC time representation, the timezone offset <i>it applies to</i>, and whether it should be treated as an absolute or localized time.<p>Edit: Corrected what type of stored offset needs to be kept

Another solution is &quot;floating time&quot; which disregards timezones entirely. This is an option in iCalendar datetime formats.<p>In floating time, 10:00 in Chile is &quot;10:00 in Chile&quot;. No timezone offset.<p><a href="https://www.ietf.org/rfc/rfc2445.txt" rel="nofollow">https:&#x2F;&#x2F;www.ietf.org&#x2F;rfc&#x2F;rfc2445.txt</a><p><a href="https://scottworldblog.wordpress.com/2009/02/20/how-to-miss-your-flight-and-other-important-life-events-courtesy-of-ical/" rel="nofollow">https:&#x2F;&#x2F;scottworldblog.wordpress.com&#x2F;2009&#x2F;02&#x2F;20&#x2F;how-to-miss-...</a>

There is a great (humorous) Computerphile video about this topic: &quot;The Problem with Time &amp; Timezones&quot; [0]<p>[0] <a href="https://www.youtube.com/watch?v=-5wpm-gesOY" rel="nofollow">https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=-5wpm-gesOY</a>

Don&#x27;t most time zone databases store the date of rule changes? <a href="http://en.wikipedia.org/wiki/Tz_database#File_formats" rel="nofollow">http:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Tz_database#File_formats</a>

Would it be possible to avoid any ambiguity at all by saving the timezone rules themselves as separate most-previous and current versions within the application context itself?<p>Then when a new set of rules is detected (perhaps notification of updates at the OS level should be turned into a standardized publish-subscribe API to avoid too many applications polling for changes all the time, especially wasteful on battery-powered devices), move the current version to the previous version, scan for timezone rule differences, then scan your collection of records that use those timezones, parse them down to only those records affected by the new rules, and finally apply corrections to those records affected by the new rules.<p>Extending further, if this approach works, perhaps an OS-level, perhaps git-backed storage of versions of timezone rules could avoid duplication of effort. Combined with a publish-subscribe service, it can auto-prune itself based upon the list of subscribed applications and when the oldest subscriber last hit the version store.

Am I missing something, or does their solution not actually solve their specific example problem case at all?<p>Saving local time plus offset is _exactly_ the same information as saving GMT, isn&#x27;t it?<p>You&#x27;d really need to save local datetime plus location... which they don&#x27;t seem to actually be recommending?<p>Of course, for actually triggering an alarm or whatever, you&#x27;d still need to plot this on the actual timeline somehow, and deal with periodically checking to see if it should be changed because of a DST or timezone rule change or whatever.

This doesn&#x27;t really seem to solve the problem, just makes some of the error modes less surprising to the user.<p>Surely the right approach to handling scheduling like this is (sticking with the calender example) a) initiating calender event is canonical (but may or may not be in the calenders local timezone) , but b) metadata about when the schedule was made and last updated is stored, and c) every future computation takes this metadata and looks up canonical (i.e. IANA) timezone&#x2F;change information every time it touches the event, and d) a warning is given to any user, at any time their localization has a change in rules that might affect their apparent wall time, plus e) any changes in the localization of the initiating&#x2F;owning calender trigger a warning for everyone.<p>Am I missing something? [edit: besides the way to format this list...]<p>(added - I should have been more clear that the server is only responsible for keeping track of the canonical event and updating clients if and when that changes. The clients will always be responsible for resolving locally apparent changes)

What about saving the present time (the datetime when the information is recorded) and the time offset as calculated at that moment? In theory then it doesn&#x27;t matter what happens, you&#x27;re still able to adjust. The only ambiguity I can think of is if leap (seconds|hours|days) are introduced, but surely you just add them on to the delta too?<p>Of course, this system fails when you suddenly travel anything approaching relativistic speeds, but I guess you could save your time delta as a velocity-time delta :)<p>Edit: I&#x27;m not actually advocating this as a solution, I just found it an interesting thought experiment.

It seems that the example provided is a poor example. Software systems compute based on some rules. If you change the rules, you must change the software. Are there other more meaningful examples?

&gt; Instead of saving the time in UTC along with the time zone, developers can save what the user expects us to save: the wall time. Ie. what the clock on the wall will say.<p>That&#x27;s not at all foolproof, although it works for the case the author describes and probably works for most people most of the time. It wouldn&#x27;t work if, for some reason, I&#x27;m entering a calendar event for something I know will happen exactly <i>n</i> hours from now.

Unfortunately, there&#x27;s an ambiguity here. Suppose that you&#x27;re going to watch the Super Bowl with your friends in Chile. So you set the appointment for 1830 local time in Chile. Then Chile changes their timezone, and your local time is wrong since the actual event is based on Eastern time, and not Chile time.

I just did a project that implemented the same solution that author mentioned.<p>For those who need a web fron-tend implementation, I would like to recommend Moment Timezone (<a href="http://momentjs.com/timezone/" rel="nofollow">http:&#x2F;&#x2F;momentjs.com&#x2F;timezone&#x2F;</a>).

If I understand the objection here the problem isn&#x27;t that the computer has the time wrong, it&#x27;s that our understanding of time is wrong.<p>The computer still has the calendar entry at the right instant in time identified when the user input the entry.

Why not just use a unix timestamp and convert to the local time format of all users? Is that a poor solution for this? Most unix timestamp to Date converters already take DST into account.<p>This also fixes the &quot;MM&#x2F;DD&#x2F;YYYY&quot;, &quot;DD&#x2F;MM&#x2F;YYYY&quot;, and &quot;YYYY&#x2F;MM&#x2F;DD&quot; fiasco as you can rely that the users computer is configured to the correct timezone&#x2F;localization settings.

this assumes both users use calendar apps that work the same way.<p>so if google fixes gcal on mobile, but the other user puts it in (unfixed) outlook, they will still miss each other.<p>date&#x2F;time is <i>hard</i>.

This article is way overthinking it. It&#x27;s better to simply store the UTC time of the event, and nothing else. Local time zone conversions can be done when displaying&#x2F;editing. Presumably at the time you are reading your calendar, your local software knows the current rules to offset from GMT.<p>We have Skype meetings all the time involving parties in different US timezones and&#x2F;or different countries. There&#x27;s no &quot;place&quot; or local time zone for the meeting. We schedule in UTC and our local software or calendar program knows what time zone we are in to display the correct local time.