3 ms·

Your dollar-store quartz watch isn't on a worldwide network communicating with other watches where there needs to be an agreement on what time it is. The watch

Your dollar-store quartz watch isn't on a worldwide network communicating with other watches where there needs to be an agreement on what time it is. The watch also expects you to notice when the time drifts and for you to correct it. That includes DST adjustments, leap second adjustments, and physically moving to different timezones. Even when using an NTP server to set your time, network latencies have to be taken into account. Otherwise, if the request took 300ms round-trip and that weren't accounted for then your machine is already 300ms off from "official" time. Depending upon what you're doing, being that far off can be critical. These are things your dollar-store quartz watch simply doesn't need to concern itself with.

pixl97 3y ago
I mean for SSL purposes, no that's not really needed that much. Micro seconds don't matter as certs typically expire on a monthly to yearly basis. And those that expire closer to monthly are typically updated on a regular basis. If you have a critical need for leap second time you're typically using your own means of NTP and not Microsofts broken ass bullshit.
- taylodl 3y ago
  > If you have a critical need for leap second time you're typically using your own means of NTP and not Microsofts broken ass bullshit. I love that statement! It reflects my 40 years experience in software - if you're doing something serious then don't use Microsoft's broken ass bullshit. I smile and remember Microsoft's origins as a gaming company. To this day that's what they're best for!
8organicbits 3y ago
> That includes DST adjustments, leap second adjustments, and physically moving to different timezones. Does it? My system/bios time is in UTC. The timezone is not managed for me, when I travel I change it. DST and leap seconds are deltas you add to UNIX epoch. Tracking the number of ticks since epoch is a simpler task, much closer to what a quartz watch attempts to do on its own. Both fail when the battery does, of course. If your end user facing application can't handle 300ms drift that seems like a bug in the application. Even stuff like TOTP generators let you apply a time delta correction and servers usually allow >1 minute drift.

pixl97 3y ago

I mean for SSL purposes, no that's not really needed that much. Micro seconds don't matter as certs typically expire on a monthly to yearly basis. And those that expire closer to monthly are typically updated on a regular basis. If you have a critical need for leap second time you're typically using your own means of NTP and not Microsofts broken ass bullshit.

taylodl 3y ago
> If you have a critical need for leap second time you're typically using your own means of NTP and not Microsofts broken ass bullshit. I love that statement! It reflects my 40 years experience in software - if you're doing something serious then don't use Microsoft's broken ass bullshit. I smile and remember Microsoft's origins as a gaming company. To this day that's what they're best for!

8organicbits 3y ago

> That includes DST adjustments, leap second adjustments, and physically moving to different timezones. Does it? My system/bios time is in UTC. The timezone is not managed for me, when I travel I change it. DST and leap seconds are deltas you add to UNIX epoch. Tracking the number of ticks since epoch is a simpler task, much closer to what a quartz watch attempts to do on its own. Both fail when the battery does, of course. If your end user facing application can't handle 300ms drift that seems like a bug in the application. Even stuff like TOTP generators let you apply a time delta correction and servers usually allow >1 minute drift.