[erlang-patches] [erlang-bugs] leap-second-enabled FreeBSD doesn't work right with R12B4 erts/emulator/beam/erl_time_sup.c; correction patch included
Sun Sep 14 07:24:18 CEST 2008
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_universal_time/1 (equivalent to calendar:now_to_datetime/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)
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.
In the message <>
dated Sat, Sep 13, 2008 at 09:00:20PM -0700,
Matthew Dempsky <> writes:
> On Sat, Sep 13, 2008 at 8:12 PM, Kenji Rikitake <> 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, 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.
>  http://en.wikipedia.org/wiki/Zoneinfo#Use_in_software_systems
More information about the erlang-patches