undefined | Better HN

0 pointsnaikrovek3y ago0 comments

why would you change the clock and not the timezone? why would you even change the timezone?

0 comments

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.

naikrovekOP3y ago

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.

jacobyoder3y ago

"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.

j / k navigate · click thread line to collapse