Even the most inexperienced developers I’ve worked with are well aware that time, and timezones in particular, are really difficult.
I’ve yet to meet anyone that has suggested using anything other than a battle-hardened standard library for time.
Does any programmer believe ALL these falsehoods? Not very likely.
Do most programmers believe AT LEAST ONE of these falsehoods? Likely.
> I’ve yet to meet anyone that has suggested using anything other than a battle-hardened standard library for time.
Many stdlibs still don't account for the most edge of corner cases -- or make it very easy to screw up anyway.
And you also need to understand your timing requirements.
If all you care about is recording a date on an invoice, you really don’t need to worry about leap seconds or smearing or whatever.
Such as storing location + date + time, because that should be unambiguous, right? Or confusing "same time tomorrow" with now + 24h. Are you even sure which one you need?
Any examples of when you need "now + 24h" instead of same time tomorrow?
For example, daylight savings may start the next day, and time will be adjusted... And everything will be done 1 hour earlier than today despite the hour on the clock being "same time" as today, so what? Other than your body needing to readjust the sleep cycles, noone else seems to actually care.
Meanwhile, when I setup cron to do something daily, I don't care about this at all, so what if on one day, the interval will be 23 or 25 hours?