# Regularly updating the time from web ?



## Spartrekus (Feb 12, 2018)

Hello, To reply the following question "Regularly updating the time from web ?", you may automatically thing about NTP.
Good choice for many installations.

The problem is that it needs a lot of libraries + perl in order to work. Sockets opening with C, studying NTP time update,... it would be possible, simple, rapid and efficient using C (or C++).
Would you eventually know a possible BSD time update from web, without overkilled solutions?


----------



## herrbischoff (Feb 12, 2018)

How about net/htpdate?

However:



> Accuracy of htpdate will be usually within 0.5 seconds (better with multiple servers).



http://www.vervest.org/htp/


----------



## aragats (Feb 12, 2018)

I guess, you can do the same in plain C:
Simplest (IMO) command line solution:
	
	



```
curl -s --head http://google.com | sed -n 's/^Date:\ //p'
```
(a slightly modified version from here)
You'll have to pass the output to `date` then.


----------



## Beastie (Feb 12, 2018)

Spartrekus said:


> Hello, To reply the following question "Regularly updating the time from web ?", you may automatically thing about NTP.
> Good choice for many installations.
> 
> The problem is that it needs a lot of libraries + perl in order to work. Sockets opening with C, studying NTP time update,... it would be possible, simple, rapid and efficient using C (or C++).
> Would you eventually know a possible BSD time update from web, without overkilled solutions?


What are you talking about?! ntpd(8) requires nothing. It's in the base.


----------



## ralphbsz (Feb 12, 2018)

Spartrekus said:


> ... NTP
> The problem is that it needs a lot of libraries + perl in order to work.


What?  NTP is installed as part of the base system, and doesn't need any libraries.  Nor does it need perl.



> Sockets opening with C, studying NTP time update,...


If you use http as a new protocol for time updates, you will also open sockets in C (what do you think a http client does, other than open a socket to a http server), and then study the time updates (meaning parse the response) in a new format?



> it would be possible, simple, rapid and efficient using C (or C++).


And it would be wrong.  The reasons that NTP is complicated are twofold: first, the same daemon can do many functions, as a simple client, and as a server.  If you are not running a NTP server, about 95% of the complexity goes away.  But more important: Adjusting the time is actually a really hard if you want to do it right.  The key concept that needs to be understood first is that there is nothing like a "correct" time.  There are many ways a computer can measure time (hardware clocks, asking other servers), but they are all only estimates.  The purpose of something like NTP is to take the various estimates, and come up with a good compromise.  A compromise that asymptotically approaches the "correct" time, while maintaining certain invariants, and given the vagaries of hardware and OS implementations.  The most important invariant is: time must never go backwards, since many server processes rely on calculating elapsed time by forming the different of two time values, and many strange things can happen if the time difference becomes negative (causality seems violated).



> ... ... without overkilled solutions?


NTP is not overkill.  It is a good and appropriate solution to a very complex problem.

If you want to write your own NTP equivalent, as a exercise in learning software design, problem analysis, and coding, then go right ahead.  Feel free to use htpdate as a starting point.  But please don't expect that you will end up with something that works as well as NTP, and expect many bugs in your initial implementation.

If this were a job interview, I would now ask you the following three questions: (a) How are you planning to deal with daylight saving time transitions, in particular given that the DST transition date gets occasionally changed by legislatures, and given that the servers you are using are not necessarily in the same time zone or legislative boundary, and may be using different definitions of DST?  (b) How are you planning to deal with leap seconds, when a minute has 61 seconds instead of the usual 60?  (c) How will your protocol behave if your servers become byzantine generals?  If you don't know how to answer these questions yet, go back to the design stage.  No, I'm not seriously expecting you to answer these questions; I'm just trying to show you how much you have to know and take into account for a correct design.


----------



## SirDice (Feb 13, 2018)

Spartrekus said:


> The problem is that it needs a lot of libraries + perl in order to work.


I think you're looking at the wrong packages.


```
root@wintermute:~ # pkg info -d openntpd
openntpd-6.2p3,2:
        ca_root_nss-3.35
```
Yeah, lots of libraries and dependencies.


----------



## Deleted member 30996 (Feb 13, 2018)

I use this in my /etc/rc.conf:


```
ntpd_enable="YES"
ntpd_sync_on_start="YES"
```

and block TCP port 123 with pf. Works fine.

I suppose there's no reason it wouldn't since looking at `netstat -an` it's using UDP.


----------



## Spartrekus (Feb 15, 2018)

Thank you all  !!!! Merci !!! Fixed  !!


----------



## gpw928 (Mar 6, 2018)

Consider using chronyd(8) if your host is a virtual machine.

It's more-or-less a plug-in replacement for ntpd(8) but handles suspension of operation, as happens with a virtual guest, much better.


----------

