graal js new Date() millisecond is not equals to the system date

[chenjie100]

The millisecond time of Graal's new Date() is not equal to the system time, and as time goes on, the time difference will become larger and larger

[oubidar-Abderrahim]

Hi, thank you for reporting this, could you please share some details on what GraalVM version you're using? and which OS?
Also, it will help significantly if you can share a reproducer code that illustrates this issue.

[chenjie100]

OS: Windows 10
GraalVM: 22.3-b11

Eg:
JS time: console.log(new Date().getTime())
Java system time: console.log(java.lang.System.currentTimeMillis());

At the beginning, there will be a few milliseconds difference, and after running for a few days, there will be a few seconds difference.

[oubidar-Abderrahim]

Hi, could you please verify if this is still occurring on the latest version of Oracle GraalVM for JDK21 & JDK17. If yes, please share a full reproducer with steps to reproduce that we can follow to verify and debug the issue. Thank you

[chenjie100]

Hello, I have tested version graalvm 23.0.2 and the issue still persists.

[chenjie100]

@oubidar-Abderrahim
Dear oubidar-Abderrahim:
I would like to ask where I can download the latest fixed version and the version that fixes this issue:
#7636

[oubidar-Abderrahim]

If yes, please share a full reproducer with steps to reproduce that we can follow to verify and debug the issue. Thank you

[chenjie100]

Please run the following code in Graalvm JS
`
let javaDate, jsDate;

do {
javaDate = new java.util.Date().getTime();
jsDate = new Date().getTime();
java.lang.System.out.println('testing...');
java.lang.Thread.sleep(1000);
} while (jsDate >= javaDate);
java.lang.System.out.println(javaDate + '-' + jsDate);
//result like: 1701133925742-1701133925741
//jsDate is executed after javaDate, but jsDate is smaller than javaDate
`

[oubidar-Abderrahim]

jsDate is executed after javaDate, but jsDate is smaller than javaDate

To my knowledge, javascript is an asynchronous language. So I am not sure how you can guarantee that jsDate is executed after javaDate?

[chenjie100]

Because the code line
"javaDate = new java.util.Date().getTime();"
before
"jsDate = new Date().getTime();"
These code is executed in order, and it did not involve any asynchronous or callback operations，so javaDate must less than or equal jsDate

[oubidar-Abderrahim]

@iamstolis could you please take a look here, Thank you

[iamstolis]

jsDate is executed after javaDate, but jsDate is smaller than javaDate

While this may be confusing, it is not necessarily a sign of a problem. Note that even new java.util.Date().getTime() can go backwards (when you change a system time or when it is corrected automatically via NTP, for example). Even if you eliminate these events, it is too optimistic to expect monotone results from two independent timers. Their precision/resolution may affect the outcome. For example:

• a less precise timer is asked at time 6: it returns 10 (because it is not precise enough).
• a more precise timer is asked at time 8 and returns 8
• a less precise timer is asked at time 9: it returns 10 still

So, you see the time combined from these timers to jump back and forth despite there is no bug in them.

In other words, I am not concerned by these tiny deviations that your test-case shows. On the other hand, I am concerned by the fact that you saw the difference of several seconds in a long running application. I can imagine how this can happen and it seems to be a bug in our implementation.

Our internal (nano) timer is implemented as fixedOffsetDeterminedAtTheBeginning + nanos since the beginning. In other word, our current implementation has the nice property of being monotone but it does not reflect changes in system time after "the beginning". I assume that some automatic corrections of the system time (via NTP, for example) are behind these larger differences that you observe (as they are reflected by the Java calls but not by the JavaScript ones).

[chenjie100]

@iamstolis
Thank you for your reply. My test cases may not explain much, and I understand what you mean. What confuses me is that the time obtained using js "new Date()" sometimes differs by more than a few minutes from the actual system time in a long running application.

[iamstolis]

I have modified the built-ins that return the current time to use Instant.now() instead of startTime + timeSinceStart, i.e., changes to the system time (manual or automatic) should be reflect by these built-ins now. This should resolve your issue.

[chenjie100]

That's great! Thanks @iamstolis for the update.