That introduces dependency of a clock which might be undesirable, just had a similar problem where i also went for hardcoding for that reason.

Interesting, haven&#x27;t heard this before (I don&#x27;t know much about testing). Is this kind of like fuzzing?

Because it should be `today + 1 year + randomInt(1,42) days`.Always include some randomness in test values.

Just skimmed the PR, I&#x27;m sure the author knows more than I - but why hard code a date at all? Why not do something like `today + 1 year`?

I&#x27;ve got some tests in active code bases that are using the end of 32-bit Unix time as &quot;we&#x27;ll never get there&quot;. That&#x27;s not because the devs were lazy, these tests date from when that was the best they could possibly do. They&#x27;re on track to be cycled out well before then (hopefully this year), so, hopefully, they&#x27;ll be right that their code &quot;won&#x27;t get there&quot;... but then there&#x27;s the testing and code that assumes this that I don&#x27;t know about that may still be a problem.&quot;End of Unix time&quot; is under 12 years now, so, a bit longer than the time frame of this test, but we&#x27;re coming up on it.

Now I feel bad for using (system foundation timestamp)+100 years as end of &quot;forever&quot; ownership relations in one of my systems. Looking now, it&#x27;s only 89 years left. I think I should use nulls instead.

Posted on HN in 2126: 100 years ago, someone wrote a test for servo that included an expiry in 2126

Don&#x27;t mistake a defused bomb for a dud.<a href="https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Preparedness_paradox" rel="nofollow">https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Preparedness_paradox</a>

I remember the reality of all the work needed to avoid issues.

Made me think of Mark Fisher&#x27;s Y2K Positive text:&gt; At the Great Midnight at the century&#x27;s end, signifying culture will flip over into a number-based counterculture, retroprocessing the last 100 years. Whether global disaster ensues or not, Y2K is a singularity for cybernetic culture. It&#x27;s time to get Y2K positive.Mark Fisher (2004). Y2K Positive in Mute.

While there was a lot of FUD in the media, there were also a lot of scenarios that were actually possible but were averted due to a LOT of work and attention ahead of time. It should be looked at, IMO, as a success of communication, warnings, and a lot of effort that nothing of major significance happened.

Exciting times with an anticlimactic end; I was in middle school, relishing the chaos of the adult world.

Another victim of the preparedness paradox.

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

Ain&#x27;t Mastadon supposed to be the good guys compared to X?What&#x27;s with purposefully breaking the browser back button to redirect to the front page? Spammy behavior

I&#x27;ll bet you one US Dollar that this is a scenario where the temporary fix becomes the permanent one. (Well, at least, permanent for a hundred years.)Some day, Pham Nuwen is going to be bitching about this test suite between a pair of star systems.

of course it is just an easy fix. it&#x27;s the kind of solution that even someone like me could write who has no understanding of the code a all. (i am not trying to imply that the submitter of the PR doesn&#x27;t understand the code, just that understanding it is unlikely to be necessary, thus the change bears no risk.but, the solution now hides the problem. if i wanted to get someone to solve the problem i&#x27;d set the new date in the near future until someone gets annoyed enough to fix it for real.and i have to ask, why is this a hardcoded date at all? why not &quot;now plus one week&quot;?

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.

10 years ago, someone wrote a test for servo that included an expiry in 2026