This sort of thing can be a real problem for bootstrappable/reproducible builds, where you want to verify that the tests all pass. For a while, GNU Guix wouldn't bootstrap with tests enabled because it wanted to build openssl-1.1.1l for some reason, and the test suite contained expired certificates. (This was especially bad in a Nix-ish environment, where changing whether or not tests run changes the build command that the derivation uses, which means that you can't turn the tests off without changing the hash of every dependent package.)
Interesting, from the title I thought it was intentional, as a "forced code review." Apparently not, but now I really like that idea!
Just skimmed the PR, I'm sure the author knows more than I - but why hard code a date at all? Why not do something like `today + 1 year`?
Any time constant will be exceeded someday.
An impossibly short period of time after the heat death of the universe on a system that shouldn’t even exist: ERROR TIME_TEST FAILURE
Hmm. Interesting to call out someone like this. Stuff happens. We're all humans. For now. At least we were back then.
i had to plant a 10 year time bomb in our SAML SP certificate because AFAIK there is no other way to do it. It’s been 7 years since then. Dreading contacting all the IDPs and getting them to update the SAML config.
Classic!
But before you judge the fix too hashly, I bet it’s just a quick and easy fix that will suffice while a proper fix (to avoid depending on external state) is written.
One of the comments:
> Us, ten years after generating the certificate: "Who could have possibly foreseen that a computer science department would still be here ten years later."
This was why there was a Y2K bug. Most of that code was written in the 80s, during the Reagan era. Nobody expected civilization to make it to the year 2000.
A comment from the PR
> Not a serious problem, but the weekdays are wrong. For example, 18-Apr-2127 is a Friday, not Sunday.
There is now many magical dates to remember - 2126 ( I think PR was updated after that comment) and 2177. There is also 2028 also somewhere.
I fixed one of these test cases too. Attached to it was a comment:
// By the time this fails, I should be sipping pina coladas on the beach.
Alas, he was still working, albeit at another firm.“Someone” please stop write Someone at every possible post, especially on X.
quite the nostalgic test to fix lol
what a nostalgic test to fix lol
But still a kludge. Better: use something equivalent to Go's testing/synctest[0] package, which lets you write tests that run in a bubble where time is fixed and deterministic.
[0] https://pkg.go.dev/testing/synctest