Storing event times, UTC issues when DST

I searched for this before asking but couldn't find anything that helps. I have a server that uses UTC, the clients can set the time of an event that the server executes daily (this is a simplification). For example someone in France wants an event to happen at 23:00 local time (22:00 UTC). I convert this to UTC and store it; the server executes happily every day at 22:00 UTC. Then come summer, now the offset is +2h with France, the server still executes at 22:00 UTC but for the user this is the wrong time as 22:00 UTC in France is now 00:00 local time.

I store in UTC because everyone says to store in UTC and to convert to the local time when outputting to the user, fine, but this doesn't work as expected for the user. I think I should store something like 23:00 French time and the server should take that and say "ok, this is 22:00 UTC today" or ok, this is 21:00 UTC today because of DST" (I am using Java with JodaTime BTW), but this contradicts what everyone says about how I should be storing it in UTC in the DB...so...what can/should I do?

If I store the local time and date with offset and when I read it (on the server which is using UTC) I do:

DateTime dbLocalHistoricDateTime = fromDB(); // suppose this 23:00 in France on the 01.01.2015 (UTC+1), 22:00 UTC on that date
DateTimeZone localZone = dbLocalHistoricDateTime.getZone();
DateTime currentLocalDateTime = DateTime.now().withZone(localZone);
DateTime localToday = dbLocalHistoricDateTime.withDate(currentLocalDateTime.getYear(), currentLocalDateTime.getMonthOfYear(), currentLocalDateTime.getDayOfMonth());
DateTime utcToday = localToday.withZone(DateTimeZone.UTC);

then utcToday contains the correct UTC time for today (21:00 UTC being 23:00 in France on the 27.04.2015, the server then can execute this event on that UTC time.

Thanks, Gabriel

Jon Skeet
people
quotationmark

If you want to represent a repeated event, you definitely need to store the local time and the time zone, and either store or decide on the policy for what to do if that time becomes invalid or ambiguous. (Suppose the user stores 02:30 - in spring that value doesn't occur at all when the clocks go forward, and in autumn it occurs twice when the clocks go back.)

But if you've got a repeated event, you possibly shouldn't store a DateTime anyway - I'd store something like a "start date" (the first date on which it should occur; a LocalDate), a time of day at which it should occur each day (a LocalTime) and a time zone ID (e.g. Europe/Paris).

Storing "local date/time and time zone" can also be important if you're storing a future event, bearing in mind that the time zone rules can change between now and then.

Storing a UTC instant is useful if:

  • The original time zone is no longer relevant (if it even existed)
  • The event isn't repeated
  • You want to be able to compare events really easily

This is particularly relevant for timestamps.

But yes, like most things in date/time handling, a simple "one size fits all" answer doesn't exist - you need to think about your context.

people

See more on this question at Stackoverflow