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)
So 32-bitness of int cant be a limitation. (That cant be a problem in Q3 2019, since Node 10 has bigint support).
OS also cant pose such a limitation, since WinAPI has GetSystemTimePreciseAsFileTime and *nix has clock_gettime(CLOCK_MONOTONIC) both are better than 1us
How could I get nanoseconds UTC timestamp string in NodeJS?
Date.now()+"000000"
shows that it lacks last 6 digits (millis), but the task was 4 (micros or better)
This 7yo question seems to address general timestamp question, and hrtime will get you just machine uptime, not real UTC time. results will be irrelevant with that of python.
What are other options?
UPD
Now, I can reword question a bit. From very simple perspective, Nodejs can be seen as a OS-independent runtime library. You write one js code and it will work quite same on all platforms. So it MUST bind most viable functions to js interface; timer functions are among them. As we saw, monotonic clock QueryPerformanceCounter() call is bound through process.hrtime()
Which function in node.js would lead to a clock_gettime(3) call on linux, or GetSystemTimePreciseAsFileTime() call on windows, and return result to js, with microseconds precision or better?
If the resolution you are looking for is microseconds then process.hrtime() should be enough.
const hrTime = process.hrtime()
console.log(hrTime[0] * 1000000 + hrTime[1] / 1000)
Alternatively you could use timestamp-nano
If you need an even higher precision you could build yourself a native node module: https://medium.com/the-node-js-collection/n-api-next-generation-node-js-apis-for-native-modules-169af5235b06
Or if you really like Python, you could execute a python script from Node: How to call a Python function from Node.js
For recent versions of Node, process.hrtime.bigint() seems to provide this.
Related
I'd like to use 'perf' to measure real execution time of a function. 'perf script' command gives timestamp when the function is called.
Xorg 1523 [001] 25712.423702: probe:sock_write_iter: (ffffffff95cd8b80)
The timestamp field's format is X.Y. How can I understand this value? Is it X.Y seconds?
X.Y is the timestamp in units of seconds.microseconds.
How this value is displayed can be looked at here. You can pass the switch --ns to perf script to display the timestamps in seconds.nanoseconds format too.
To understand this value, you need to understand how the perf module calculates timestamps. You can associate each event with a different clock function to compute the timestamps. By default, perf uses sched_clock function to compute timestamps for an event, more details here.
event->clock = &local_clock;
But you can use the -k switch along with perf record command to associate an event with various clockids.
-k, --clockid
Sets the clock id to use for the various time fields in the
perf_event_type records. See clock_gettime(). In particular
CLOCK_MONOTONIC and CLOCK_MONOTONIC_RAW are supported, some
events might also allow CLOCK_BOOTTIME, CLOCK_REALTIME and
CLOCK_TAI.
Adding the -k switch to perf record command will enable various clock functions depending on which clockid you use, as can be seen here.
sched_clock function shall return the number of nanoseconds since the system was started. A particular architecture may or may not provide an implementation of sched_clock() on its own. The system jiffy counter will be used as sched_clock(), if a local implementation is not provided.
Note that, all of the above code snippets are for Linux kernel 5.6.7.
X.Y is the raw format of the date. The perf's time function, which operates in nanoseconds, needs to be converted to a human readable format. Use this website to convert it to date, http://www.timestamp.fr/ , or using bash
date -d #25712
Python's documentation for time.monotonic() states:
Return the value (in fractional seconds) of a monotonic clock, i.e. a clock that cannot go backwards. The clock is not affected by system clock updates. The reference point of the returned value is undefined, so that only the difference between the results of consecutive calls is valid.
New in version 3.3.
Changed in version 3.5: The function is now always available and always system-wide.
Does the last sentence imply that for Python >= 3.5 the values returned by time.monotonic() can be safely used and compared across multiple threads?
I came across the same problem and it seems NO , getting around 10 microseconds difference across threads.
I'm on Linux, Python 3.7.5, Kernel 5.3.0-40-generic , CPU AMD Ryzen 5 3600
I want to get the runtime of an active task. In the REST API page of /applications/[app-id]/stages/[stage-id], I can get tasks info in detail.
enter image description here
You can see, the executorRunTime is 0 when a task is not completed. I think I can get the runTime according to launchTime. Suppose the launchTime is 2017-12-21T03:15:31.106GMT. I use the following code to compute the runTime.
val format = new SimpleDateFormat("yyyy-MM-dd'T'hh:mm:ss'.'sss'GMT'", Locale.ENGLISH)
format.setTimeZone(TimeZone.getTimeZone("GMT"))
val launchTime = format.parse("2017-12-21T03:15:31.106GMT").getTime
val runTime = Calendar.getInstance(TimeZone.getTimeZone("GMT")).getTimeInMillis -
launchTime
But I get a negative number. Is the time format wrong? Or what?
TL;DR
String launchTimeString = "2017-12-21T03:15:31.106GMT";
launchTimeString = launchTimeString.replaceFirst("GMT$", "Z");
long launchTime = Instant.parse(launchTimeString).toEpochMilli();
long runTime = System.currentTimeMillis() - launchTime;
(Sorry, I can write only Java 8 code, I will have to trust you to translate.)
java.time and ISO 8601
The date and time classes from Java 1.0 and 1.1 are long outdated, and SimpleDateFormat in particular notoriously troublesome. I recommend you stop using them and use java.time, the modern Java date and time API instead. It is so much nicer to work with.
Your launch time string is a bit funny. It resembles the ISO 8601 standard format with the characteristic T between the date and the time, but has a non-standard GMT in the end, where strings following the standard would usually have Z (or a positive or negative offset from UTC). Since the modern date and time classes parse ISO 8601 as their default, that is, without any explicit formatter, and since writing format pattern strings seems to be an endless source of bugs (it certainly isn’t just you), I found it tempting to modify your string to fit the standard and then parse it.
What was wrong in your format pattern?
There are two bugs in you format pattern string:
You want uppercase HH for hour of day. Lowercase hh is for hour within AM or PM, in the interval 1 through 12. With SimpleDateFormat this bug usually “just” means that an hour of 12 is understood as 00 (which would have given you a very long run time) (the modern DateTimeFormatter more eagerly tells you you have a bug if you try the same with that class).
While lowercase ss is correct for seconds, milliseconds are uppercase SSS. This must have been what hit you: 106 in you string was taken to be seconds rather than milliseconds, so if running your code before 03:16:46, you got a negative run time.
So both bugs boil down to: Format pattern strings are case sensitive, so you need to beware the correct case.
Links
Oracle tutorial: Date Time, explaining how to use java.time.
Wikipedia article on ISO 8601.
I have been trying to find a nice way to format a timestamp of the current date & time with milliseconds using Python 3's native time library.
However there's no directive for milliseconds in the standard documentation https://docs.python.org/3/library/time.html#time.strftime.
There's undocumented directives though, like %s which will give the unix timestamp. Is there any other directives like this?
Code example:
>>> import time
>>> time.strftime('%Y-%m-%d %H:%M:%S %s')
'2017-08-28 09:27:04 1503912424'
Ideally I would just want to change the trailing %s to some directive for milliseconds.
I'm using Python 3.x.
I'm fully aware that it's quite simple to get milliseconds using the native datetime library, however I'm looking for a solution using the native time library solely.
If you insist on using time only:
miliSeconds = time.time()%1*1000
time() returns accurately the time since the epoch. Since you already have the the date up to a second, you don't really care this is a time delta, since the remaining fraction is what you need to add anyway to what you have already to get the accurate date. %1 retrieves the fraction and then I convert the numbers to millisecond by multiplying by 1000.
note
Note that even though the time is always returned as a floating point
number, not all systems provide time with a better precision than 1
second. While this function normally returns non-decreasing values, it
can return a lower value than a previous call if the system clock has
been set back between the two calls.
Taken from https://docs.python.org/3/library/time.html#time.time. But this means there is no way to do what you want. You may be able to do something more robust with process_time, but that would have to be elaborate.
I am hoping to get a quick answer to one question about NodaTime before downloading it. So far, I am reading about NodaTime and its API and it seems very carefully thought out.
I hope it might help eliminate some of the chaos I've been encountering in an application that has a database back-end, a desktop client with a database provider, and a web client that must run on the major browsers. The support for ISO 8601 on DateTime and Time varies greatly on the various database, database provider, and web platforms. Internet Explorer, for example, follows ISO 8601 but SQL Server does not; web UI timepickers do not because Chrome does not.
QUESTION: In NodaTime, is 24:00 a valid Time value? Is 24 a valid argument for the hours parameter of its Time constructors?
BACKGROUND: ISO 8601 allows for two representations of midnight: 00:00 for "midnight this morning" and 24:00 for "midnight tonight". When the DateTime object is on the time-line, a date whose time element has 24:00 coincides with the next day at 00:00. They are the same time-line instant with two different representations, both representations valid per ISO.
A Time-only value is detached from the time-line. A time of 00:00 occurs at the beginning of the detached 24-hour day and a Time-only value of 24:00 is 24 hours after 00:00. A Time type should accept 24 in the hour. When 24 is the hour the maximum value for seconds and milliseconds and ticks is 0 (unless modulo arithmetic is involved and the time rolls over, so that 24:01 is 00:01 -- but ISO has nothing to say about this implementation detail, IIRC).
We accept 24:00 when parsing a LocalDateTime, but not 24:01.
This was issue 153, implemented in revision f7ac0365d8ca.
Unfortunately this was after the 1.0 release, so you'll either need to grab the current code, or wait for 1.1 to be released (hopefully soon).
We don't currently accept it when parsing just a LocalTime. If you want that, please log a feature request - we'd probably look at it for 1.2 (which will have a lot of text features), although I'm not sure what the representation would look like. (LocalTime itself doesn't support the idea of "end-of-day midnight".)