Best practice when working with code that uses current data and time

All programing languages have some method of referencing the current date and time. Examples... now() sysdate DateTime.Now() current_timestamp Get-Date In a professional or semi-professional environment should any of these actually be used within a procedure? or should dates and times only be passed in as variables? Consider a couple of pretty basic rules for simple code development and lifecycle... Code should be identical in development, test and live environments Test results should be repeatable. The same input data should always result in the same output. Both of these are rules are hard/impossible to implement with code that contains references to the current date. Consider a PL/SQL block with a SQL query that references SYSDATE, running the code un-altered will give different results depending on whether it's run on the 6th, 7th or 8th of June (test results no longer repeatable). If you're testing and you want to ensure the same results every time then you could hack the procedure to hard-code to a fixed day - but then you wouldn't really be testing the same code that's in development or live. So what's the current best-practice for dealing with this? Just scrap the two rules I've listed above? or always pass dates and time as parameters to a function? or something else?

Jun 8, 2025 - 13:00

All programing languages have some method of referencing the current date and time. Examples...

now()
sysdate
DateTime.Now()
current_timestamp
Get-Date

In a professional or semi-professional environment should any of these actually be used within a procedure? or should dates and times only be passed in as variables?

Consider a couple of pretty basic rules for simple code development and lifecycle...

Code should be identical in development, test and live environments
Test results should be repeatable. The same input data should always result in the same output.

Both of these are rules are hard/impossible to implement with code that contains references to the current date. Consider a PL/SQL block with a SQL query that references SYSDATE, running the code un-altered will give different results depending on whether it's run on the 6th, 7th or 8th of June (test results no longer repeatable). If you're testing and you want to ensure the same results every time then you could hack the procedure to hard-code to a fixed day - but then you wouldn't really be testing the same code that's in development or live.

So what's the current best-practice for dealing with this? Just scrap the two rules I've listed above? or always pass dates and time as parameters to a function? or something else?