1. 5
  1.  

  2. 1
    {:ok, 7200, 0}
    # 7200 seconds is two hours
    

    It most certainly is not! At least, not always. It could be 2:00:00, 1:59:60, or even 2:00:01 if we ever end up doing a negative leap second.

    I’d imagine given the author’s work on this topic that their code correctly handles positive and even negative leap seconds. But I get nervous when people reference an hour in terms of 3600 seconds.

    1. 2

      That function ignores leap seconds. The documentation states this. The example is in March and there won’t be a leap second in March. They are either at the end of June or December.

      The library does have limited leap second support. I have thought about supporting leap seconds in more functions. But it is not the highest priority.

      One big issue is that most operating systems do not support leap seconds. Because of the upcoming leap second I have tried to set the time to just before the leap second on a Ubuntu virtual server. And run some tests. But it if you simply run date, it just isn’t supported. It is not supported by the Erlang calendar module either.

      In most cases leap seconds are not as big a problem as time zones and DST. The risk of being off by 1 second once every 18 months is not as bad as being off by 3600+ seconds for long periods of time.

      As for negative leap seconds they have not happened yet. If the earth starts to slow down that much I will have to change some code :)