Uses for "Days Since 2000"
Yes, this block is useful. This article exists to give some examples because it is commonly and incorrectly thought of as being "useless".
(days since 2000)
It reports the number of days since the start of the year 2000 in UTC. The year itself isn't that important, it's just an "epoch" we are measuring in relation to. It could be 1970 like the Unix epoch or it could be any other date, though round numbers are easy to remember.
The number reported by the block is actually quite precise, down to fractions of a second. You can convert it to seconds by multiplying by 86400 (the number of seconds in a day):
set [seconds since 2000 v] to ((days since 2000) * (86400))
As an alternative to the timer
set [start time v] to (days since 2000) // reset timer
set [timer v] to (((days since 2000) - (start time)) * (86400)) // get elapsed time in seconds
You can have multiple timers being reset whenever you want. Just create more variables (or even list items) storing the start times.
Sub-frame times
The time reported by this block updates more frequently than Scratch's frame rate. This allows for more accurate times, essential for applications such as profiling performance.
set [start time v] to (days since 2000)
... // code you want to measure
set [elapsed time v] to (((days since 2000) - (start time)) * (86400))
Another use is in preventing scripts from running too long. If you want to target a particular frame rate, slow scripts could be stopped if detected as being over a given time limit. I used this in my project Procedural Sandbox to ensure the user interface remains responsive even whilst rendering the scene.
define example // run without screen refresh
set [start time v] to (days since 2000)
repeat (10000)
if <(((days since 2000) - (start time)) * (86400)) > [0.0333]> then // example time limit of 1/30 sec
stop [this script v]
end
...
end
Simple date/time comparisons
The time being a single value is very easy to compare. No need to separately handle hours/minutes/seconds or calendar days/months/years. The time reported is roughly the same across all devices and does not consider the time zone. This leads to a few use cases:
Timed events
An in-project event could occur or expire at a given time.
set [is event active? v] to <<(days since 2000) > [9330.5]> and <(days since 2000) < [9331.5]>>
Of course there is the downside that you'll have to calculate the number to compare with.
Cloud sync
A dynamic game world such as one with a 20-minute day/night cycle can be implemented without any need for sending this between players (all players can calculate the events happening from their own time).
set [time of day v] to ((((days since 2000) * (1440)) / (20)) mod (1)) // counts from 0.0 to 1.0 every 20 mins
The time can be included in data packets sent through cloud variables. Old data for example could be ignored.
Save code tracking
If the time is stored in the save code, the elapsed time can be found when loaded later. Consider an idle game where you earn currency over a long time. The next time the save is loaded, the amount of currency earned over that time can be calculated. Time-based rewards such as "daily rewards" could also be implemented.
I personally include the time in my save code implementations as a backup or aid in tracking save versions (though should not replace an actual version numbering system).
Time zone finding
The "current date/time" block accounts for the time zone. It is possible to calculate the user's time zone from this and days since 2000. Example
Bonus info
According to my gathered project block statistics, I use the days since 2000 block two times more than the timer.
A few years ago I stated that the days since 2000 block is more accurate than the timer so recommended it based on that. My testing at the time showed the timer deviated at low framerates. Testing now however shows they are same. I don't know what happened, perhaps an update to Scratch or my computer/browser fixed it.