[jeroenhd]

> However, the code was so poorly written that the system would lose data during the double 1 am window that occurs during daylight savings time shift. > [...] > Many people in this thread are treating this like some sort of display of incompetence, but if you've ever written code that deeply interacts with time, you'd know how difficult it is to get right.

Your example only speaks for the incompetence argument.

In reality, times and dates are really complicated. Luckily, the engineers at Facebook, Reddit, and Clouflare are being paid hundreds of thousands of dollars to show off their expertise. Is it that much to ask for them to read into details like leap seconds?

[lavishlatern]

It is too much. I was Google SRE and there is an internal meme showing a time series graph jumping backwards during the double 1am at DST. These mistakes happen everywhere and are best avoided by a system that doesn't allow them to happen in the first place.

[nullc]

So advocates of memory safe (or even high level, period) programming languages are just showing off their incompetence in your book?

Would you say to an advocate of C (much less ... rust): Look man, real programmers write in boolean circuits. Programming is hard, sure, but the engineers at Facebook, Reddit, and Clouflare are being paid hundreds of thousands of dollars to show off their expertise. Is it that much to ask for them to read into details multiplication circuits?

:)

Leapseconds causing widespread failures isn't a hypothetical, just like buffer overflows aren't. Yet, in theory, with perfectly competent development ...

Yet even with perfect competence leapseconds are still pretty gnarly: They require systems have a trustworthy and consistent source of the list of leapseconds. ... and they mean that you fundamentally cannot predict the amount of time between two UTC timestamps when one or more of them is more than 6 months in the future... and no amount of competence can fix that.