# Anecdotal erroneous use of NTP

**URL:** <https://community.ntppool.org/t/anecdotal-erroneous-use-of-ntp/3230>\
**Category:** Client Configuration and Development\
**Created:** [February 9, 2024, 3:51pm UTC](https://community.ntppool.org/t/anecdotal-erroneous-use-of-ntp/3230 "2024-02-09T15:51:42Z")\
**Posts on this page:** 1\
**Page:** 1

<div class="post-metadata">

**Author:** ![ebahapo](https://sea2.discourse-cdn.com/flex016/user_avatar/community.ntppool.org/ebahapo/32/1152_2.png) [@ebahapo](https://community.ntppool.org/u/ebahapo)\
**Post date:** [February 9, 2024, 3:51pm UTC](https://community.ntppool.org/t/anecdotal-erroneous-use-of-ntp/3230/1 "2024-02-09T15:51:42Z")

</div>

[Curious tale of broken VPNs, the Year 2038, and certs that expired 100 years ago](https://www.theregister.com/2024/02/09/it_incident_report_the_clock/)

Had an NTP client been used to discipline the clock from different redundant sources, instead of resetting the time periodically from a single source, the wild server would be safely ignored as a false ticker and this issue in a comercial VPN service would have never happened. And, no, it was not any problem with NTP, but with the system engineering.