I found this on the show and tell page. https://scratch.mit.edu/projects/273365840/#player
It uses the

along with the

to make a clock accurate down to a Tenth of a Second.

Is this a new idea or is it just a known method that I never heard of?

Well, the ‘current’ block isn't too precise, so it makes sense to exploit blocks like ‘days since 2000’ and ‘timer’. The issue with using ‘timer’ is that it's not guaranteed to be synchronised with the actual time, so if you start the project in the middle of a second, the millisecond component would be out-of-synch.

The project resolves this like so (simplified):

This block detects when the ‘current second’ block changes its value, which is the point where a second has just ended and hence the millisecond component is 0. Hence, reset the ‘timer’ so it also has a millisecond component of zero.

'days since 2000' has the (dis)advantage of being UTC.

Extracting the milliseconds from it doesn't line up with the ‘timer’ milliseconds (it's out by a fraction), but maybe that's okay because you can extract the seconds, etc. from ‘days since 2000’ too.

jokebookservice1 wrote:

This block detects when the ‘current second’ block changes its value, which is the point where a second has just ended and hence the millisecond component is 0.

Ooh, I'm nitpicking here, but this won't work if more than a whole second passes between the times when Scratch executes these frames, e.g. lots of lag, or if the system time changes (maybe, try it yourself, don't quote me). Instead you'd want to do “not current second < future time”. Although..maybe I'm missing a point here

_nix wrote:

jokebookservice1 wrote:

This block detects when the ‘current second’ block changes its value, which is the point where a second has just ended and hence the millisecond component is 0.

Ooh, I'm nitpicking here, but this won't work if more than a whole second passes between the times when Scratch executes these frames, e.g. lots of lag, or if the system time changes (maybe, try it yourself, don't quote me). Instead you'd want to do “not current second < future time”. Although..maybe I'm missing a point here

If you have any lag (except an exact integer amount), the milliseconds will no longer line up with the timer and none of it works anyway!

jokebookservice1 wrote:

_nix wrote:

jokebookservice1 wrote:

This block detects when the ‘current second’ block changes its value, which is the point where a second has just ended and hence the millisecond component is 0.

Ooh, I'm nitpicking here, but this won't work if more than a whole second passes between the times when Scratch executes these frames, e.g. lots of lag, or if the system time changes (maybe, try it yourself, don't quote me). Instead you'd want to do “not current second < future time”. Although..maybe I'm missing a point here

If you have any lag (except an exact integer amount), the milliseconds will no longer line up with the timer and none of it works anyway!

This got technical quickly!

I'd just use days since 2000. Timing loops that depend on relative time are prone to having small errors accumulate, and if you're trying to create absolute time out of a relative time loop, then if lag happens as _nix and jokebookservice are getting at, your time is going to be wrong until you restart the project. It's better to start off with absolute time sources from the beginning, like days since 2000. You can compare days since 2000 with current [x] to figure out the time zone offset.

i just say

Woah this is new to me