Yet another pitfall: Changing the system clock on runners can throw off billing and calculation of used minutes. Colleague of mine told me about that one last year.
I miss the days of setting the clock/date to avoid time bombs in software builds. "back in my day, things were so much easier!" now, I would not be surprised if the teams working on these kinds of lock outs are larger than the teams building the product.
Potentially, maybe? I didn't follow it closely enough, but the crux was a group trying to test out various time-related calls, and they'd set the base time of the containers to different times forward and behind 'now'. There were hundreds/thousands of minutes 'billed', going over the account threshhold, stopping all builds. But... I don't remember hearing if there was some diff between 'negative' charges and 'positive' charges.
Because sometimes you want to change it to a date many months or years in the future. That kind of thing as a test to make sure nothing goes wrong based on the date, like Y2K/Year 2038, or malicious code that's designed to lay dormant until some point in the future.
that is a very naive way to go about that, i think, for reasons exactly like jacobyoder discovered. Seems to me that it would be much better to write code which allows you to override the time seen by your software by setting some delta specified in an environment variable or something, or by having test cases which test your logic without requiring that the notion of the current time be changed.
Changing the current time will do unknown things to other software running on the system, and there are too many question marks there for that to seem reasonable, to me.
"But you can't really know what it will be like if you just change an env in one area - what if you miss something? Or what it someone changes some code later that doesn't respect the env var?"
"well... that's what tests are for, right? We'll write more tests to ensure usages of these timezone/date/time specific areas are covered".
"Someone will miss something. I missed something years ago and it was bad. We can't rely on that. We have to change the actual server instance clock to ensure we can verify this behaviour works correctly".
When I pointed out that what we were testing was a scenario that wouldn't ever really exist in real life - mobile clients not using 'real' time (they're almost all synced to satellites and time servers you typically can't override) hitting a server that also may be set to a vastly different time (not synced to a timeserver with a few ms drift).... I was dismissed as "not understanding the problem".
There's a need to say "how might this perform in 8 months, when DST changes". But... you'd set both client and server to the same future (or past) time. This was setting up a server to be days/weeks in future, then testing 'now' clients against it, which "worked" somehow, but imo was just giving weird false assurances that a hypothetical scenario worked that wasn't ever going to happen in real life. Basically couldn't happen in real life under normal conditions.
I miss the days of setting the clock/date to avoid time bombs in software builds. "back in my day, things were so much easier!" now, I would not be surprised if the teams working on these kinds of lock outs are larger than the teams building the product.