[erlang-questions] calendar now_to_universal_time/1 vs. universal_time/0

[Kenneth Lundin]

On Mon, Sep 27, 2010 at 10:50 PM, Alexander Harju
<alexander.harju@REDACTED> wrote:
> On Mon, Sep 27, 2010 at 9:15 PM, Ryan Zezeski <rzezeski@REDACTED> wrote:
>
>> On Mon, Sep 27, 2010 at 1:00 PM, Ulf Wiger
>> <ulf.wiger@REDACTED>wrote:
>>
>> >
>> > On 27 Sep 2010, at 18:25, Pierpaolo Bernardi wrote:
>> >
>> > > On Mon, Sep 27, 2010 at 18:21, Ryan Zezeski <rzezeski@REDACTED>
>> wrote:
>> > >
>> > >> This is, essentially, the question I'm asking.  Should I prefer one
>> over
>> > the
>> > >> other for *any* reason?  Right now, I prefer universal_time because
>> it's
>> > >> less typing :)
>> > >
>> > > A perfectly good reason.  It's also a tiny bit clearer.
>> >
>> > erlang:now() is actually a bit different from the calendar clock.
>> > It can, by definition, never jump backwards.
>> >
>> > It will also attempt not to make large adjustments of any kind, so if it
>> > detects
>> > that there is a large difference between the system clock and the
>> > erlang:now()
>> > clock, the now() clock will speed up or slow down 1% in order to converge
>> > with the actual time, without disturbing timeouts etc. which rely on
>> now()
>> > to
>> > provide a smooth representation of system real-time.
>> >
>> > In other words, erlang:universal_time/0 will return the actual time,
>> > whereas
>> > erlang:now() may, under certain circumstances, differ quite significantly
>> > from actual time.
>> >
>> >
>> Thanks Ulf, but I was actually referring to calendar:universal_time/0.  I
>> did not know of the existence of erlang:universtaltime/0 until you pointed
>> it out just now.  Now I'm curious, what is the difference, if any, between
>> these two?  Is their existence just a case of history?
>>
>> Another question, both functions claim that they return UTC "if available"
>> otherwise they return local time.  In what case is UTC not available?
>>
>
> calendar:universal_time() calls erlang:universaltime() so the difference is
> just another function call.
>
> Regarding now().
> You shouldn't call calendar:now_to_universaltime(now()). That doesn't make
> any sense at all.
> now() has to be unique, therefore it's MUCH slower.
> The only time it make sense to to use calendar:now_to_universaltime(...) is
> when you have a now-timestamp and want to convert it to universal-time.
>
> If you need a timestamp higher precision than seconds I recommend to write
> your own now-nif to get rid of the penalty of now().

If you need a timestamp with the same precision as now() but without the
penalty of now() always returning increasing unique times and the compensation
for sudden jumps in time you can use os:timestamp() which returns a
value with the same
format as now() but directly from the OS. This can be valuable if you
for example want to
put timestamps in logs and later compare with timestamps generated by
other programs
on the same machine.
So there is no need to write your own NIF.

os:timestamp/0 was introduced in June 2009 in the R13B01 release.

/Kenneth Erlang/OTP Ericsson.
>
> // Alex
>
>
>>
>> -Ryan
>>
>