How should I deal with ambiguous local time?

Question

I have a database which stores timestamp, and a UI frontend which contains a date/time field and a time zone field, where the user is supposed to enter the local time into the UI for convenience. Specifically, I am recording the start and end times of past (not future) local events.

The date/time is converted to UTC timestamp internally in PHP code, and the time zone is stored in a separate column, which can be retrieved to get the local time again.

The exact timestamp is important as it is used to calculate statistics based on the real point in the time, not the local representation.

How should we handle user input if the local time is ambiguous e.g. due to DST change?

Answer 1

The situation is more complicated than just the hour of overlap during DST transitions. Time zone rules may be updated causing DST transitions to occur at different dates. Sometimes this occurs only weeks before the actual DST transition. Systems that are not updated in time might only see this change after the user has already input time for a past event, causing the calculated UTC to become invalid. Additionally, sometimes time zones are abandoned or modified altogether, and again those updates might not have reached your system. PHP has a built-in time zone database so you need to update your PHP or the PECL timezonedb package to see these changes.

All of which is a very long-winded way of saying this: there is no way to reliably determine the offset of a local time to UTC except by asking the user. Show a (calculated) offset field next to the time zone field and let the user correct it if necessary. Use the offset instead of the time zone to calculate UTC. Or, just stop caring so much about correctness and tolerate a little fuzziness. Most likely your users will care more about ease of use than correctness, so make a trade-off accordingly.

Answer 2

The most important part here is transparency - the UI should tell the users precisely how DST is handled, so they don't have to guess. Normally, I would expect such an UI to take care of DST automatically (as PHP usually does, as long as you keep the PHP installation up-to-date). DST seasons are unambiguous in most cases once the time zone is known. So if your requirements allow a failure of one hour in those rare edge cases where the automatism may fail, a simple UI label or tool tip like ("DST is handled automatically") may be enough. It can be helpful to let the UI display the "winter time" and/or the UTC it calculates from the input.

However, if you really expect you have to deal with those cases where the automatism may fail, or if you cannot guarantee the DST calculation to be updated in case the rules change), give users a possibility to override the automatism. Offer the user a two- or three-valued option field "DST" nearby the date/time field, with values

• "take care automatically"
• "winter time"
• "summer timer

to let the users specifify their intent. Let the UI also show the time it calculates from the input.

Answer 3

Take DST in Europe. (Not sure whether at 02:00 or 01:00, the latter seems more logical.)

There is one Sunday where at 03:00 the clock is reset to 02:00. This means that 2 O'Clock AM is repeated. In general it does not hurt when exactly in UTC 02:46 actually happens.

There is also one Sunday where the hour 02:00 is missing. When the use enters a wrong time for that day, 02:46, if the client/server validation does not report an input error, it does not seem that terrible too.

If you need to be exact for those two Sundays, ensure validation for the missing hour, and for the duplicate hour 02:00 in Octobre ask a confirmation

The hour 02 is duplicated:

(*) Still summertime     ( ) Already standard (winter) time

Java has some means in ZonedDateTime (withEarlierOffsetAtOverlap, withLaterOffsetAtOverlap). For ambiguity detection see @JodaStephen's answer.

public boolean isExtraHour(final ZonedDateTime time) {
  return time.getZone().getRules().getValidOffsets(time.toLocalDateTime()).size() > 1;
}

PHP should have means too, otherwise patch the input to become 2 hours out of the overlap, and add the correct offset to the UTC.