15

I am designing a scheduling web app. I expect events to be added by users in several different timezones and locales. The challenge is correct presentation of these events.

So, as an example:
if a user is in EST timezone and is looking at a webinar event that was added by another user in PST, I want to convert the actual PST time of event into a local time for viewer. So, if an event is scheduled for 2 PM PST, then it should shown as 5 PM EST.

I also want to be careful that performance does not take a hit if there are thousands of events which may require a conversion from actual event time to the viewer's local time.

All thoughts and comments are appreciated.
TIA

user2754571
  • 251
  • 3
  • 14

1 Answers1

49

In general, scheduling future events is a complex subject. You have to make a distinction in the context of what is going to be scheduled:

  • Does the event occur at a specific universal instant in time? If so, you should record the event time in terms of UTC.

    For example, a task that runs every 24 hours would be scheduled by UTC time and not by the local time. It might start off at some local midnight, but as daylight saving time changes take effect it could be running at 23:00 or 01:00 by the local clock.

  • However, if the event is scheduled by human beings, it is likely to be in terms of a local time, so you should record it that way.

    For example, a meeting that occurs at 08:00 Eastern Time will always occur at that local time. In the winter, that would be 13:00 UTC, and in the summer it would be at 12:00 UTC.

    So in this context, you cannot record the scheduled start time in terms of UTC. This is a very common mistake, as there is a ton of advice on the Internet that says "always store using UTC", which would be wrong in this scenario.

    Instead, you should store two values - the local time such as 08:00 and its IANA time zone identifier, such as America/New_York. You may also need to store a recurrence pattern or specific date depending on how the event is scheduled.

  • Consider using Joda Time instead of Java's Calendar or Date classess. It will save you from many headaches. Make sure you read the Joda Time documentation and understand how it works.

    Joda Time has all of the functions you will need for converting between one time zone and another - which I believe was the primary concern of your question.

  • Be sure to have a procedure in place for updating the time zone data regularly. Updates are pushed out multiple times a year, as the governments of the world make changes to the legal definitions of their time zones. You cannot just deploy it once and forget about it.

  • Also be sure you understand that conversion from local time to a specific UTC moment is not a perfect function due to daylight saving time. If an event is scheduled during an invalid or ambiguous local time, you should have a strategy for detecting and dealing with that in your application. You might just apply some assumptions, or you might want to go out of your way to ask the user what to do.

    For example, if I schedule an event at 2:00 AM Eastern Time every day, then on March 10th 2013, that time does not exist. Should the event occur at 3:00 AM? Or should it not occur at all?

    Another example, if I schedule an event at 1:00 AM Eastern Time every day, then on November 3rd, 2013, that time occurs twice. Should the event happen at the first (daylight time) instance? Or at the second (standard time) instance? Or both? Should I assume one or the other, or should I ask the user which they mean?

    Only you can decide what to do, as it is your application. But ignoring the problem will likely lead to errors.

  • Once an event has passed, you can record it in UTC if you wish, or record it with the full local date time and offset. Either are acceptable. This works just fine for singular past events, just not for recurring future ones.

Community
  • 1
  • 1
Matt Johnson-Pint
  • 230,703
  • 74
  • 448
  • 575
  • Thanks for detailed response Matt. I expect that almost all events will be created by humans. My thought is to save the timezone and milliseconds, so I know the actual local time of the event and would be able to convert it into the viewer's timezone. You are correct, this not as simple as it seems to be ... – user2754571 Oct 05 '13 at 03:41
  • 1
    If you store milliseconds, such as from `Date.getTime()`, that will be in UTC, not local time. If the time zone rules get changed before your time occurs, then it could be the wrong value. In several parts of the world, these time zone change happen frequently, so its very difficult to be sure that a future local time will align with a future UTC instant. (I did say this was complicated. :) ) – Matt Johnson-Pint Oct 05 '13 at 17:37
  • 1
    You should probably use a `LocalDateTime` from JodaTime (and a time zone). What DB are you storing these in? – Matt Johnson-Pint Oct 05 '13 at 17:38
  • Dang! You are correct about UTC Matt, but my thought is that I would convert it using the local TZ and millis which should give me the local time. I am using MySQL. I haven't used JopdaTime before but will certainly look at that solution. Would I run into a problem converting to the viewer's date time if I store event creator's local DateTime and TZ? – user2754571 Oct 09 '13 at 00:53
  • That should be ok, just watch out for DST issues as I described. – Matt Johnson-Pint Oct 10 '13 at 02:01
  • I'm also one of those who don't understand the ton of advice that says "_always store using UTC_". I expect most of the time it would be the local time with the timezone, or the absolute time (a.k.a. the epoch time or the POSIX time). – musiphil Aug 14 '15 at 02:28
  • I have a lot of trouble with this answer. You can't say the meeting will "Always" be at 8:00 eastern time, that would confuse everyone else in the world who had to deal with your meeting from another timezone. It's a process problem (Which is the EXACT same problem with databases storing timezone-based information). Twice every year the time of your meeting is changing, to not reflect that in your database is a very poor way to communicate. – Bill K Mar 15 '17 at 20:30
  • @BillK - Sure you can. My daily standup is at 10:00 AM Pacific. It was at 10:00 Pacific last week before the US DST change, and it's still at 10:00 Pacific this week after the US DST change. Reflecting the daily occurrence time in any other manner (including UTC) would mean cancelling the meeting and scheduling a new one. – Matt Johnson-Pint Mar 15 '17 at 20:48
  • @MattJohnson That only works because your team is mostly in the same timezone. This is the same assumption that causes everyone who uses databases that store times in "local time" to tear their hair out and start screaming "USE UTC" on every message board they can find. With a cross-timezone team you would find yourself required to be more specific and to announce the fact that you are now changing the meeting time twice a year. – Bill K Mar 15 '17 at 20:50
  • @BillK - Even if there are those that are in a different time zone, the meeting itself is scheduled based on some particular time zone. That is the originating event. Sure - our DST shift could mean it ends up in some other time for someone in a different zone, but that doesn't mean you change the meeting to be scheduled in UTC. – Matt Johnson-Pint Mar 15 '17 at 20:56
  • @BillK - Also, "Use UTC Everywhere" is shortsighted. Besides scheduling rules, date-only values such as birth dates also need to be left alone and not converted to UTC. – Matt Johnson-Pint Mar 15 '17 at 20:58
  • @Matt Suppose 15 people on your team were in timezones that went into DST at different times than you. How do they know when to call in? What's the easiest way to communicate your meeting change--write up an email to each participant using https://en.wikipedia.org/wiki/Daylight_saving_time_by_country or simply reschedule the meeting? A lack of foresight is what we are combating when we say "Always use UTC"--not that it can't be made to work, but just that the easiest way doesn't usually scale well. – Bill K Mar 15 '17 at 21:05
  • @MattJohnson Explain the algorithm for finding all the people born at the same time as you across the world using your theory about birthdays. I honestly couldn't imagine doing that without weeks of development time and testing (as opposed to seconds to write a query if it was stored in UTC). However, if you are talking about "Birthday" that is not a time, it is a recurring date (January 1) without necessarily even having year information attached. – Bill K Mar 15 '17 at 21:11
  • Summary: If you use an approach where a meeting time is set with localtime+timezone, and the timezone tables change, no one needs to change their software, just ensure it still gets table updates. It will be correct for everyone still. If you use Bill's approach, the data is static, so you need to reschedule the meeting to ensure it still runs at the same local time. – oligofren Mar 29 '22 at 15:51