DateAndTime is way less precise on Windows than on Unix

[jecisc]

On windows if you do DateAndTime now = DateAndTime now you get true because you need to wait at least 1 millisecond to get two different DateAndTime instances from #now. On unix you get false because they have a precision at the nanosecond.

This is problematic because first the API let you think you can manipulate this at the level of the nano second. And second because DateAndTime now is used to generate unique IDs in the system and that means that if we create ID too fast on windows, we end up with same IDs.

[svenvc]

That is why, for example, UUIDGenerator also uses a counter and a random element.

You should also check if the file exists.

Like Stef suggested, we already have FileReference class>>#newTempFilePrefix:suffix:

[labordep]

Hi, we have this problem in our UI library (Toplo), our tests on Windows (Pharo 11 and Pharo 12) are not passing.
To test, DoIt on this in a Windows playground and a Mac playground :
DateAndTime now < DateAndTime now
The result in Windows is false, in Mac it is true.

For a unit test we need to write aTimestamp <= anotherTimestamp instead of aTimestamp < anotherTimestamp. This is dirty :(

Another precision, in Windows I have already 6 zeros digits in my DateAndTime now nanos value and 3 zeros digits on Mac. So the result of DateAndTime < is not the same because of :

[guillep]

The code that computes that is here: https://github.com/pharo-project/pharo-vm/blob/de760673b5f108d32576b47f4bbdfd3b230520b0/extracted/vm/src/common/heartbeat.c#L113
There are different implementations between windows and *nix based systems.

In *nix systems we are using gettimeofday, maybe we should move to clock_gettime as proposed by this post https://stackoverflow.com/questions/69099750/what-is-the-precision-of-the-gettimeofday-function?

The equivalent of clock_gettime in windows is no trivial, but we could port such a solution :)
https://stackoverflow.com/questions/5404277/porting-clock-gettime-to-windows