[erlang-questions] microseconds since midnight

[Henning Diedrich]

Thanks for the suggestion, Jayson.

Thinking about it, that simplicity may make it less error prone when 
coping with a possible one-sided roll over right when two sides compare 
their timestamps. It may just 'look' less controlled than 'midnight' as 
the fix point that eventually isn't fixed at all. I'll keep it in mind.

Henning

Jayson Vantuyl wrote:
> Is it important that it reset at midnight?  Would it be acceptable to have a 4-byte value that increased but just rolled over occasionally (instead of each morning)?
>
> Otherwise, you could just convert the time to an integer and then take the modulus to mask it down.
>
> On Jan 8, 2010, at 4:11 PM, Henning Diedrich wrote:
>
>   
>> Thanks for the education.
>>
>> I was actually looking for something as reliable as now(), i.e. deriving the milliseconds since midnight (subj line of post was simplifying) to get a relative, reliable four byte sync value to be sent across systems.
>>
>> I came up with the following. Bearing my original question in mind, maybe you can see at a glance if this is safe. Or, since it needs to be done often, could be done cheaper. Thanks a lot!
>>
>> Henning
>>
>>
>> %% Milliseconds since midnight. ------------------
>>
>> nightsynctime_offset() ->        {_, Time_1} = erlang:universaltime(),
>>   SSMN_1 = calendar:time_to_seconds(Time_1),
>>   {MegaSec_2, Seconds_2, _} = now(),
>>   % MidNightOffset =
>>   (MegaSec_2 * 1000000) + Seconds_2 - SSMN_1.
>>  nightsynctime(MidNightOffset) ->
>>
>>   {MegaSec_3, Seconds_3, MicroSec_3} = now(),
>>   % NightSyncTime =
>>   (MegaSec_3 * 1000000 + Seconds_3 - MidNightOffset) * 1000
>>    + trunc(MicroSec_3 / 1000).
>> %% Test ------------------------------------------------
>>              start() ->
>>
>>   secondtimes(),
>>   MidNightOffset = nightsynctime_offset(),
>>   loop(MidNightOffset, 0).
>>
>> loop(MidNightOffset, LastSync) ->
>>
>>   SyncTime = nightsynctime(MidNightOffset),
>>   io:format("~p~n", [SyncTime]),
>>     % test (do in the day, obviously)
>>   if SyncTime < LastSync -> exit("counting backwards") ; true -> ok end,
>>     timer:sleep(166),
>>   loop(MidNightOffset, SyncTime).
>>   Output:
>>
>> 328986
>> 329153
>> 329320
>> 329487
>> 329654
>> 329821
>> ...
>>
>>
>>
>> Ulf Wiger wrote:
>>     
>>> -----BEGIN PGP SIGNED MESSAGE-----
>>> Hash: SHA1
>>>
>>> Henning Diedrich wrote:
>>>  
>>>       
>>>> Hi,
>>>>
>>>> are now() and universaltime() incrementing their seconds count at the
>>>> exact same time?
>>>>
>>>> So that the seconds from calendar:time_to_seconds(universaltime()) and
>>>> the microseconds from now() could simply be added up S*1000000+Ms?
>>>>
>>>> Or would that risk having the microseconds going back to zero at
>>>> different times then when the seconds counter is counted up?
>>>>    
>>>>         
>>> now() is not guaranteed to show accurate wall-clock time. It is
>>> guaranteed to always increment at least by one microsecond for each
>>> call. It also normally adjusts its speed by up to 1% if it detects
>>> a deviation from the system clock. This is to ensure that the
>>> "real-time clock" of Erlang doesn't suddenly make a big leap in
>>> time just because some clueless operator changed the system time
>>> (or the system clock is in a time zone that obeys DST). As
>>> Erlang timers rely on now(), big leaps can either cause all timers
>>> to fire at once, or all of them going into deep sleep for a looong
>>> time, both of which can be equally disastrous.
>>>
>>> os:timestamp() looks like a now() object, but reads the system clock,
>>> and should behave the way you want. This function is a recent
>>> addition - R13, I think.
>>>
>>> BR,
>>> Ulf W
>>> -----BEGIN PGP SIGNATURE-----
>>> Version: GnuPG v1.4.9 (GNU/Linux)
>>> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>>>
>>> iEYEARECAAYFAktHwNcACgkQtqqFieqzed1W7ACg92GMvW6WaN6vFRjyc3qzcaQM
>>> +ZoAn3Obne7EZk2gF2029IEgVgWUFeXv
>>> =XIOf
>>> -----END PGP SIGNATURE-----
>>> ---------------------------------------------------
>>>
>>> ---------------------------------------------------
>>>
>>> WE'VE CHANGED NAMES!
>>>
>>> Since January 1st 2010 Erlang Training and Consulting Ltd. has become ERLANG SOLUTIONS LTD.
>>>
>>> www.erlang-solutions.com
>>>
>>>
>>> ________________________________________________________________
>>> erlang-questions mailing list. See http://www.erlang.org/faq.html
>>> erlang-questions (at) erlang.org
>>>
>>>
>>>  
>>>       
>
>
> ________________________________________________________________
> erlang-questions mailing list. See http://www.erlang.org/faq.html
> erlang-questions (at) erlang.org
>
>
>