moved this topic here because it's not a bug but a misunderstood from your part :)
so readiness notification only works if the daemon provide the feature and it's not the case with ntpd. For example dbus-daemon have an options called --print-pid(refers to it man pages), this option allow to write a the given file descriptors(e.g 3), in this case you can use @ notify = 3 to specify s6-supervise to read the fd (file descriptor) and wait for an event. When the daemon is ready, dbus-daemon will write the fd and so s6-supervise know that the daemon is really ready.

Now the @ notify (aka notification-fd) can only contain an unsigned int (positive integer value ). By default on linux system the fd 0 is used for stdin(standard input), fd 1 is used for stdout(standard output) and fd 2 is used for stderr(standard error). So the first fd available should be 3, that's why , in the majority of the case, you will see @ notify = 3.

hope it's a little more clear

the reason is:
if you start a service with 66-start or 66-all by default the API will use -U. With this option the API expect to find a notification-fd at the service directory. If the notification-fd is not found the API will change automatically the -U by -u option and warm the user about the change. I realized that behaviour can confuse users and i will make a few changes about this on the next 66 release.
So, this is just a warning and it can be ignored safely.

hum, maybe something it can be interesting to test (never tried), skarnet implement it own ntp client:
https://github.com/skarnet/s6-rc/blob/master/examples/source/ntpclient/run
somethings may need to be changed like the server address...
it easy to convert it to 66 frontend, just remove the shebang and the fdmove -c 2 1 line and copy the rest into your key @ execute value and declarate it as classic service(no dependencies is needed).
Tell us if you get something relevant

save this at /etc/66/sysadmin/service/my_ntpd

[main]
@ type=classic
@ name=my_ntpd
@ description="my ntpd daemon"
@ user=(root)
@ options=(log)

[start]
@ build=auto
@ execute=
(
	if
	{
		pipeline
		{
			s6-setuidgid ntp
			backtick -n NTPSERVERIP
			{
				pipeline { s6-dnsip4 -t 16000 0.fr.pool.ntp.org }
				s6-head -n 1
			}
			importas -u NTPSERVERIP NTPSERVERIP
			s6-sntpclock -v 2 $NTPSERVERIP
		}
		s6-clockadd -e 120000
	}
	s6-setuidgid nobody
	s6-sleep 14400
)

disable the ntpd daemon and enable this one

shebang: language interpreter -> # !/usr/bin/bash , # !/usr/bin/execlineb -P, # !/usr/bin/python, ...
this is the first line that you see in a scripts file
note:s6-dns need to be present on your system

@ fungalnet

Plz, update s6-networking and tell us if that work now. Thx

Edit: You can manually try like that for a test from your user:

s6-dnsip4 -t 16000 pool.ntp.org

In most cases it's best to use pool.ntp.org to find an NTP server (or 0.pool.ntp.org, 1.pool.ntp.org, etc if you need multiple server names). The system will try finding the closest available servers for you

that will output some address IP. Take one of them and execute

s6-sntpclock -v2 $ADDRESS_IP | s6-clockview

ntpclient-66serv service package is now available on Obarun 66service repo.

s6-sntpclock: fatal: time uncertainty too large

you need to force the update, i think...
try this one, make a file in /etc/66/sysadmin/service/ntpclient

[main]
@ type=classic
@ name=ntpclient
@ description="ntpclient daemon"
@ user=(root)
@ options=(log env)

[start]
@ build=auto
@ execute=
(
    if
    {
        pipeline
        {
            s6-setuidgid ntp
            backtick -n NTPSERVERIP
            {
                pipeline { s6-dnsip4 -t 16000 pool.ntp.org }
                s6-head -n 1
            }
            importas -u NTPSERVERIP NTPSERVERIP
            execl-cmdline -s { s6-sntpclock ${CMD_ARGS} -v2 $NTPSERVERIP }
        }
        execl-cmdline -s { s6-clockadd ${CMD_ARGS} }
    }
    s6-setuidgid nobody
    s6-sleep 14400
)

[environment]
!CMD_ARGS=-f

then 66-enable -f -S ntpclient
see what's happen. if all is good change the /etc/66/conf/ntpclient and replace the CMD_ARGS=-f by an empty one (meaning CMD_ARGS=), than 66-start -r ntpclient to reload the configuration file.
An option will come soon on 66-start to properly handle such a case when the configuration file is needed to be changed on the fly. Work like a charm on my machine but...

no, the -f options is only needed when you have a big difference between your clock and the time coming from the server, so like i said you edit the file /etc/66/conf/nptclient as this

!CMD_ARGS=

yeah you should able to change your country side, and yes ntpd as nothing to do with ntpclient. so if you are satisfied you can remove the opennptd package and the associated service.
trick: you create an another variable in the [environment] section like this

!CMD_ARGS=
!COUNTRY=<my_country>.pool.ntp.org

and change this line in the service file declaration

pipeline { s6-dnsip4 -t 16000 ${COUNTRY} }

now you should be able to change your country like you want simply editing the /etc/66/conf/ntpclient and doing a 66-start -r ntpclient command :). This can be usefull if you want to test multiple country.

@ fungalnet

Should I leave the -f permanently?

Two days ago, during my test, I asked to skarnet, the author of the software why -f option is not set by default and I got this answer.

The assumption with these tools is that if you're getting crazy time (either because your clock has gone insane, or because the other source has gone insane) it's way better to fail and raise an alarm than it is to blindly work.
The exception is when your local clock has a totally unreliable value, such as devices without a battery, without CMOS, and that just booted - so they have no idea what date/time it is. In which case, to get a sensible starting point, you accept the first thing a NTP server tells you and that's what the -f option is for.

About the default value time defined for this option I got this answer

It's a reasonable one, because: clocks drift, it's common to see a drift of one second and what is the maximum value I should use, how to calculate this value but generally a call to a NTP client is made before they drift too much and it's very rare that a drift goes above 1 second so 2 seconds of accepted delta is not too big but is safe you just need to guesstimate it, but unless you have very specific circumstances I suggest you just go with the default.
Most networks are reliable enough that you'll get way under 1 second delta and most clocks are reliable enough that you won't drift more than 2 seconds between 2 calls to s6-sntpclient. My servers have a service that call s6-sntpclient something like once every 6 hours if you trust your system clock, you can make that once every 24 or 48 hours in any case that's rare enough not to cause any inconvenience to your network or to the NTP server, and often enough to catch any drift before it becomes too big

/etc/66/service is the default directory where pacman install the service file (so, packager directory), the /etc/66/sysadmin/service is a sysadmin directory and NEVER touched by pacman.
So, now you have a service that you want to change because the dev did a bad service file declaration (F@ # ^#{\ dev), make a copy of the service from /etc/66/service to /etc/66/sysadmin/service and work on this one. When the @ # ^{\ dev will realize his mistake he will update the package and pacman will overwrite the /etc/66/service file.
Well, in fact you never loose your own changes.
This behaviour is equal for an user, if you want to do some change on a given service make a copy from the original to /home/<user>/.66/service.

Now, when you enable a service with root privileges the first directory checked to find the service is /etc/66/sysadmin/service than if the service was not found it will search at /etc/66/service. So your service is always took before the original one.
This is the same for an user, the first directory checked is /home/<user>/.66/service than /etc/66/sysadmin/service than /etc/66/service. That's mean that a sysadmin can rectify a service which it will be available for all users on the machine ;).