Incorrect Timer.stamp() value for JS?

Calling Timer.stamp() ( JS target) , return as example 0.3772999999523163
Eval will return 1633461404.56267095

In generated code it use Date.now() divide by 1000 ( to return seconds) . but still the result is not correct.

Here is the haxe generated JS code and what Date.now() return

(function ($global) { "use strict";
class HxOverrides {
	static now() {
		return Date.now();
	}
}
class Test {
	static main() {
        console.log("Timer: "+Date.now());
		console.log("Timer Haxe : " + HxOverrides.now() );
	}
}
class haxe_iterators_ArrayIterator {
	constructor(array) {
		this.current = 0;
		this.array = array;
	}
	hasNext() {
		return this.current < this.array.length;
	}
	next() {
		return this.array[this.current++];
	}
}
if(typeof(performance) != "undefined" ? typeof(performance.now) == "function" : false) {
	HxOverrides.now = performance.now.bind(performance);
}
{
}
Test.main();
})({});

The value itself might differ depending on platforms, only differences between two values make sense.

Yes, I read this, but from the generated code it seems that the idea is to use the Date.now() / 1000 function , but something change this behavior.

Ok, so the only way to get current time should be Date.now().getTime() which created new Date().getTime(); in JS.

In JS Date,now() and new Date().getTime() return same value , but getTime() maybe is twice as slow . Still you can’t access JS function Date.now() from haxe without js untyped

For me this is very strange behavior and for getting current date in miliseconds should be used Date.now().getTime() for JS , Sys.time for cpp, neko and even Timer.stamp() for some targets.

Ok, thank you for your time.

How about js.lib.Date.now() ?

Yes, that will work.
Thank you.

Still it’s a little bit strange behavior of Haxe. At example:

If I want to get miliseconds for JS, eval, Hashlink , i should do something like that:

  1. Using methods available on all platforms
    var ms = #if js Date.now().getTime(); #else Timer.stamp()*1000; #end

  2. Using target specifics methods
    var ms = #if js js.lib.Date.now() ; #else Sys.time()*1000; #end

For me it is inconsistent behavior ( (1) available for all platforms ) , and it’s more Haxe implementation rather how language ( JS) works in that case.

You don’t want to use Timer.stamp() to get the current utc time on any platform - that’s not its function, it’s only a coincidence that it gives you this on some platforms and it may change in the future. it’s typically used for measuring time differences when running your program

For getting calendar time, the haxe Date class is what you need to use Date - Haxe 4.2.1 API

For performance measuring, you take two samples with Timer.stamp(), which is performance.now() on js

1 Like

Thank you! My goal was to to get unix epoch time in milliseconds ( for all platforms).
It’s possible , but with #if … if you want to get milliseconds

In generated JS code I saw only return Date.now() , but not performance.now() and for that , for me, it was strange behavior.

Still, it will be good to have one unify solution available for all platforms to get current time in miliseconds ( unix epoch time in milliseconds)

If you use Date.now().getTime(), you should get millisecond precision on all platforms (excluding neko, which is deprecated). The docs says it’s only second-level precision but reading the source indicates when used this way it’s millisecond precision

There’s a gotcha for some systems where you get second-level precision, but I guess it doesn’t happen very often because it should work for macOS windows and linux

Not exactly.
For Eval and Hashlink ( neko too) miliseconds are always 000

Example here : Try Haxe ! ( you can select from Options → Hashlink )

ahhh! Damn, right you are – agree it would be nice to get current unix time on all platforms with ms precision

Yes, indeed.
Right now if I want to get milliseconds in Hashlink , I should do :
Int64.fromFloat(Sys.time()*1000) , because Sys.time return 5 digits after decimal and Time.stamp() return same ( for Hashlink)