ambiguous results for UTC to Local conversions

[benmmurphy]

This doesn't make sense to me. UTC refers to an instant in time and looking at the DST rules there is only 1 valid rule for each instant in time. So going from UTC->local time there should not be any ambiguity.

21> localtime:utc_to_local({{2015,10,25}, {1,0,3}}, "Europe/London").
[{{2015,10,25},{1,0,3}},{{2015,10,25},{2,0,3}}]

but at UTC 1:03 the local time was definitely 1:03. In fact if you put in 2:03 local time and ask for a UTC conversion you get:

22> localtime:local_to_utc({{2015,10,25}, {2,0,3}}, "Europe/London").
{{2015,10,25},{2,0,3}}

so local_to_utc(utc_to_local(X)) doesn't even round trip.

[dhull]

You're right, UTC to local time should never be ambiguous. It looks like there is a bug in localtime:utc_to_local.

However, local time to UTC is ambiguous. If I'm reading the Olson timezone database for London correctly.

# Rule  NAME    FROM    TO      TYPE    IN      ON      AT      SAVE    LETTER/S
Rule    EU      1981    max     -       Mar     lastSun  1:00u  1:00    S
Rule    EU      1996    max     -       Oct     lastSun  1:00u  0       -

# Zone  NAME            GMTOFF  RULES   FORMAT  [UNTIL]
Zone    Europe/London   0:00   EU      GMT/BST

This says that the next second after 1:59:59 BST is 1:00:00 GMT, which meant that 1:03 local time occurred twice.

2> localtime:local_to_utc({{2015,10,25}, {1,0,3}}, "Europe/London").
[{{2015,10,25},{1,0,3}},{{2015,10,25},{0,0,3}}]

Since the BST/GMT distinction is not represented in Erlang's datetime() representation, local_to_utc(utc_to_local(X)) may produce two datetime()s and utc_to_local(local_to_utc(X)) may fail.