[erlang-patches] [erlang-bugs] leap-second-enabled FreeBSD doesn't work right with R12B4 erts/emulator/beam/erl_time_sup.c; correction patch included

[Kenji Rikitake]

I also think using time2posix(3) and posix2time(3) will be a better way
than timegm(), as Matthew describes.

I've also found out that the following three functions

calendar:now_to_datetime/1
calendar:now_to_universal_time/1 (equivalent to calendar:now_to_datetime/1)
calendar:now_to_local_time/1

do not work in the leap-second-enabled environment, due to the fact that
erlang:now/0 shows the internal clock value as is, with gettimeofday(2).
The converted results of the functions include the offset of 
((TAI-UTC) - 10)
seconds.

Modifying erlang:now/0, defined as get_now() in erl_time_sup.c to
include the offset of time2posix(3) is a possible solution, though I
don't feel like to doing it because it will surely break the assumption
of continuous monotonous increasing of erlang:now/0.

Fixing only the calendar module functions by adding a time2posix(3)
calculation routine written in C somewhere in the BEAM BIFs looks better
to me, though I need to investigate further.

Regards,
Kenji Rikitake

In the message <cf683a060809132100g6527575bi4a50e31293479d45@REDACTED>
dated Sat, Sep 13, 2008 at 09:00:20PM -0700,
Matthew Dempsky <matthew.dempsky@REDACTED> writes:
> On Sat, Sep 13, 2008 at 8:12 PM, Kenji Rikitake <kenji.rikitake@REDACTED> wrote:
> > mktime() certainly is, but timegm() isn't, AFAIK.
> 
> My mistake.  I confused the local-vs-UTC time functions.
> 
> time2posix(3) and posix2time(3) come from Olson's tz library, which
> according to Wikipedia[1], is pretty widely used, so they seem like
> they should be reasonably portable.  Anywhere that doesn't have them
> probably isn't leap second aware anyways.  They're also present in
> FreeBSD, NetBSD, and OpenBSD's cvs trees from over 10 years ago, so
> they're hardly recent additions either.
> 
> [1] http://en.wikipedia.org/wiki/Zoneinfo#Use_in_software_systems
>