одно и то же время практически нереально получить с большой точностью, тут тебе правильно подсказал @eryx67 - векторные часы. Они гарантированно решат проблему последовательности событий

мне большая точность не нужна .. секунды

От того что в otp перенесли бы ntp сумма слагаемых бы не изменилась

что вы хотели этим сказать  ?

Правильный ответ – зависит от настроек виртуальной машины. См http://erlang.org/documentation/doc-11.1/erts-11.1/doc/html/time_correction.html#time-warp-modes

При настройках по-умолчанию время может отличаться.

Лучше использовать os:system_time

ну я вот тоже туда склоняюсь

если вопрос только в запросах к процессу на удаленной ноде,
то вообще ничего со временем делать не нужно, выполняйте на ноде,
пересылайте себе

Parent = self(),
ProxyF = fun () ->
                    Res = call_my_server(),
                     Parent ! {self(), Res}
                 end,  
RemotePid = spawn(RemoteNode, ProxF),
receive
     {RemotePid, Res} -> Res
after Timeout ->
      {error, timeout}
end

нет . мне надо быть уверенным . что сообщение пришло в положеное время . иначе его отбросить

ну так поставите временную метку на ноде, где сервер и все

видимо неверно понял. думал претензия к erlang, что он не предоставил механизм синхронизации времени между хостами.

Да и даже NTP не поможет, хардварь может двигать время как хочет, могут быть скачки напряжения и всё такое. У меня вон на raspberry pi регулярно умирают часы. А в момент тяжелой нагрузки NTP может не получиться и на нормальном сервере, например пакет может просто не влезть в канал, быть обрубленным, потерянным (это же всё-таки UDP) или отложенным роутером более чем на секунду

NTP можно использовать, чтобы делать всякие вещи более оптимально, а вот рассчитывать на NTP просто нельзя

monotonic_time гарантирует только что следущее запрошенное значение не меньше предыдущего. В реальности, (на той же raspberry pi) этот monotonic_time может несколько секунд выдавать одно и то же значение

А между нодами это значение может сильно отличаться (хотя я где-то читал, что monotonic_time медленно синхронизируются в рантайме)

Оно медленно синхронизируется с системным временем, а не с нодами

Спасибо за поправку, а где про это можно прочитать, кстати?

в erl_time_sup.c в коде beam можно посмотреть,
там простой код, где описано, не помню, к сожалению.

ну если очень сильно теоретизировать, то можно к каждому серверу присобачить независимый источник каких-нибудь стабильных колебаний и один раз синхронизировать все эти источники, ну типа атомные часы к каждому серверу приделать

тогда, мне кажется, можно какие-то гарантии предоставлять

но в реальном мире это будет слишком дорого и походу ненужно

Нужно просто прикрутить к серверам квантово запутанные частицы и всё.

зачем к серверу. в otp

согласен, и на любой вызов метода “гет статус” отвечать “ваш платеж находится в состоянии неопределенности”

Платёжная система "Шрёдингер" 😆