Unified utc nanoseconds timestamp: os.get_utc_time()

[sleonovich]

Problem

python3 has possibility running following construct:

from datetime import datetime
print({'timestamp':str(int(datetime.utcnow().timestamp() * (10**9)))})

That would output JSON-like structore: {'timestamp': '1567658264143923968'}

Now I want to get similar result in Node.JS 12.

• I need a string
• I need UTC stamp since 1970, but not since machine boot
• Error no more than last 4 digits (microseconds precision or better)

---

Possible solution

• WinAPI has GetSystemTimePreciseAsFileTime
• *nix has clock_gettime(CLOCK_MONOTONIC)

bot are os-stuff and has to be exposed through this module like os.get_utc_time(), in a single unified function, that returns corresponding bigint. that's superobvious and supersimple to implement

---

Alternatives you've considered

• Date.now()+"000000" shows that it lacks last 6 digits (millis), but the task was 4 (micros or better)

• process.hrtime.bigint() returns machine uptime, not UTC-1970

[bnoordhuis]

Related: https://github.com/libuv/libuv/issues/1674 - related in the sense that it needs to happen before it can be implemented in node.

That issue has been open for a while and hasn't seen much movement so far. You should volunteer if you want to see it go through. :-)

*nix has clock_gettime(CLOCK_MONOTONIC)

CLOCK_MONOTONIC starts counting from some arbitrary point in time, not the UNIX epoch.

CLOCK_REALTIME starts at 1970-0-01 but can jump back in time (leap seconds, DST changes.)

I think (but am not 100% sure) that python's datetime.utcnow() is just a wrapper around gettimeofday(), which itself is like CLOCK_REALTIME but with no better than microsecond resolution.

process.hrtime.bigint() returns machine uptime, not UTC-1970

Not quite. The starting point is some arbitrary point in time, meaning that even if it's the system uptime on your machine, it's not guaranteed to be that on other people's machines.

[sleonovich]

Okay, lets start with linux first (I was windev, I want to rest of it) Let's look at gettimeofday first at lines 140 or 255 (same idea for needs) (https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/kernel/time/time.c?h=v5.4-rc1) No matter what, that leads to ktime_get_real_ts64 in timekeeping.c That thing seems to keep ns, as good as it can... So wat's the problem exposing os api function?

That's really good stuff to do this as a modern way to get some UTC (maybe as a bigint) up to ns precision! You may discuss that with your dev crew, I feel a little shy to commit in such a major repo..

[sleonovich]

So basically we have to attach this system internals call to the end user, just as api does (no need to invent bicycle, just great possibility to work on nanoseconds scale.. for example, you want to send it to influxdb?

[sleonovich]

That's really up to you... Please, consider this improvement, add new API, and it needs deeper investigation to add some +3 decimal precision digints to JSON.stringify(new Date())

[bnoordhuis]

That thing seems to keep ns, as good as it can... So wat's the problem exposing os api function?

gettimeofday() returns its result in a struct timeval and as the field name tv_usec suggests, that's in microseconds, not nanoseconds.

clock_gettime() returns its result in a struct timespec and that struct has a tv_nsec field. However, then you need to decide on what clock source to use.

To complicate matters: macOS, for example, didn't have clock_gettime() until recently. Libuv still uses mach_absolute_time() for that reason.

At any rate, libuv/libuv#1674 needs to be closed out before Node.js can make the requested changes and that issue can use volunteers so don't be shy. :-)

[github-actions[bot]]

There has been no activity on this feature request for 5 months and it is unlikely to be implemented. It will be closed 6 months after the last non-automated comment.

For more information on how the project manages feature requests, please consult the feature request management document.

[github-actions[bot]]

There has been no activity on this feature request and it is being closed. If you feel closing this issue is not the right thing to do, please leave a comment.

For more information on how the project manages feature requests, please consult the feature request management document.