Sync SyncIO.realTime* methods with Clock implementation

[satorg]

Otherwise, Clock[SyncIO].realTimeInstant might not be the same as SyncIO.realTimeInstant.
Discussed on Discord.

Also adds SyncIO.realTimeZonedDateTime, similar to IO.realTimeZonedDateTime.

[satorg]

Hmm... The CI failure doesn't seem relevant to me:

[error] sbt.librarymanagement.ResolveException: Error downloading org.typelevel:cats-effect-laws_3:3.5.2
[error]   Not found

[durban]

In theory we could split this into 2 parts: the fix, and the new method. The fix could go into 3.6.x. (But I'm not sure it's worth it.)

[satorg]

I can create a separate PR without realTimeZonedDateTime, if necessary. This one could go 3.7, the other one would go straight to 3.6 then. Just let me know what works the best. Thank you!

[durban]

Honestly, I'm not sure it's worth the hassle. You seem to be the first to notice the bug, so if you don't need the fix in 3.6.x, then let's leave this as it is. (I mean the PR is fine as it is.)

[durban]

ZoneOffset.UTC.getTotalSeconds

Is this a fancy way of writing 0?

[satorg]

Yeah, probably you're right.. To be honest, I didn't give it much thought.

Also, I'm not really sure what the point of getting ZonedDateTime instance is when its offset is always 0. But this is how the original method Clock.realTimeZonedDateTime works.

[satorg]

@durban , I changed ZoneOffset.UTC.getTotalSeconds to 0, because it was really unnecessary. But the PR may need yet another approval. Thank you!

[durban]

Thanks, it was quite fine before; I tend to make remarks that are not crucial, just suggest possible improvements and/or for my own education. 👍