LocalDateTime.now() has different levels of precision on Windows and Mac machine
When creating a new LocalDateTime
using LocalDateTime.now()
on my Mac and Windows machine i get a nano precision of 6 on my Mac and a nano precision of 3 on my Windows machine. Both are running jdk-1.8.0-172
.
- Is it possible to limit or increase the precision on one of the
machines? - And why is the precision actually different?
java precision java-time platform
|
show 4 more comments
When creating a new LocalDateTime
using LocalDateTime.now()
on my Mac and Windows machine i get a nano precision of 6 on my Mac and a nano precision of 3 on my Windows machine. Both are running jdk-1.8.0-172
.
- Is it possible to limit or increase the precision on one of the
machines? - And why is the precision actually different?
java precision java-time platform
1
LocalDateTime.now()
uses the systemClock
which means whatever precision the system clock has that's how much precisionLocalDateTime.now()
will have.
– Slaw
Aug 26 '18 at 20:18
"milliseconds precision of 6" is that the same as microsecond precision? (Perhaps better phrased as "subsecond precision").
– Andy Turner
Aug 26 '18 at 20:18
Sorry! It´s actually called "nano".
– Tobias Marschall
Aug 26 '18 at 20:21
@Slaw RunningSystem.currentTimeMillis()
provides the same level of precision on both machines.
– Tobias Marschall
Aug 26 '18 at 20:23
5
The systemClock
may useSystem.currentTimeMillis()
or a higher resolution clock if available. It looks like your Mac has a clock with microsecond precision.
– Slaw
Aug 26 '18 at 20:28
|
show 4 more comments
When creating a new LocalDateTime
using LocalDateTime.now()
on my Mac and Windows machine i get a nano precision of 6 on my Mac and a nano precision of 3 on my Windows machine. Both are running jdk-1.8.0-172
.
- Is it possible to limit or increase the precision on one of the
machines? - And why is the precision actually different?
java precision java-time platform
When creating a new LocalDateTime
using LocalDateTime.now()
on my Mac and Windows machine i get a nano precision of 6 on my Mac and a nano precision of 3 on my Windows machine. Both are running jdk-1.8.0-172
.
- Is it possible to limit or increase the precision on one of the
machines? - And why is the precision actually different?
java precision java-time platform
java precision java-time platform
edited Aug 26 '18 at 20:32
YCF_L
32.9k104082
32.9k104082
asked Aug 26 '18 at 20:15
Tobias MarschallTobias Marschall
6331621
6331621
1
LocalDateTime.now()
uses the systemClock
which means whatever precision the system clock has that's how much precisionLocalDateTime.now()
will have.
– Slaw
Aug 26 '18 at 20:18
"milliseconds precision of 6" is that the same as microsecond precision? (Perhaps better phrased as "subsecond precision").
– Andy Turner
Aug 26 '18 at 20:18
Sorry! It´s actually called "nano".
– Tobias Marschall
Aug 26 '18 at 20:21
@Slaw RunningSystem.currentTimeMillis()
provides the same level of precision on both machines.
– Tobias Marschall
Aug 26 '18 at 20:23
5
The systemClock
may useSystem.currentTimeMillis()
or a higher resolution clock if available. It looks like your Mac has a clock with microsecond precision.
– Slaw
Aug 26 '18 at 20:28
|
show 4 more comments
1
LocalDateTime.now()
uses the systemClock
which means whatever precision the system clock has that's how much precisionLocalDateTime.now()
will have.
– Slaw
Aug 26 '18 at 20:18
"milliseconds precision of 6" is that the same as microsecond precision? (Perhaps better phrased as "subsecond precision").
– Andy Turner
Aug 26 '18 at 20:18
Sorry! It´s actually called "nano".
– Tobias Marschall
Aug 26 '18 at 20:21
@Slaw RunningSystem.currentTimeMillis()
provides the same level of precision on both machines.
– Tobias Marschall
Aug 26 '18 at 20:23
5
The systemClock
may useSystem.currentTimeMillis()
or a higher resolution clock if available. It looks like your Mac has a clock with microsecond precision.
– Slaw
Aug 26 '18 at 20:28
1
1
LocalDateTime.now()
uses the system Clock
which means whatever precision the system clock has that's how much precision LocalDateTime.now()
will have.– Slaw
Aug 26 '18 at 20:18
LocalDateTime.now()
uses the system Clock
which means whatever precision the system clock has that's how much precision LocalDateTime.now()
will have.– Slaw
Aug 26 '18 at 20:18
"milliseconds precision of 6" is that the same as microsecond precision? (Perhaps better phrased as "subsecond precision").
– Andy Turner
Aug 26 '18 at 20:18
"milliseconds precision of 6" is that the same as microsecond precision? (Perhaps better phrased as "subsecond precision").
– Andy Turner
Aug 26 '18 at 20:18
Sorry! It´s actually called "nano".
– Tobias Marschall
Aug 26 '18 at 20:21
Sorry! It´s actually called "nano".
– Tobias Marschall
Aug 26 '18 at 20:21
@Slaw Running
System.currentTimeMillis()
provides the same level of precision on both machines.– Tobias Marschall
Aug 26 '18 at 20:23
@Slaw Running
System.currentTimeMillis()
provides the same level of precision on both machines.– Tobias Marschall
Aug 26 '18 at 20:23
5
5
The system
Clock
may use System.currentTimeMillis()
or a higher resolution clock if available. It looks like your Mac has a clock with microsecond precision.– Slaw
Aug 26 '18 at 20:28
The system
Clock
may use System.currentTimeMillis()
or a higher resolution clock if available. It looks like your Mac has a clock with microsecond precision.– Slaw
Aug 26 '18 at 20:28
|
show 4 more comments
2 Answers
2
active
oldest
votes
The precision is different because LocalDateTime.now()
uses a system default Clock
.
Obtains the current date-time from the system clock in the default time-zone.
This will query the system clock in the default time-zone to obtain the current date-time.
...
The link in this Javadoc takes you to Clock.systemDefaultZone()
which states (emphasis mine):
Obtains a clock that returns the current instant using the best available system clock, converting to date and time using the default time-zone.
This clock is based on the best available system clock. This may use System.currentTimeMillis(), or a higher resolution clock if one is available.
...
Which clock Java uses can depend on a lot of things and it looks like your Mac computer has a clock with microsecond precision whereas your Windows computer has a clock with millisecond precision. I'm not aware of any way to increase the precision of a clock but you can definitely decrease the precision so that it matches across platforms.
One option is to do as Ole V.V. does in his answer and use LocalDateTime.truncatedTo(TemporalUnit)
.
Another option is to plug in your own Clock
and use LocalDateTime.now(Clock)
. If possible, I would use Clock.tickMillis(ZoneId)
since this method returns a Clock
that truncates to milliseconds.
Obtains a clock that returns the current instant ticking in whole milliseconds using the best available system clock.
This clock will always have the nano-of-second field truncated to milliseconds. This ensures that the visible time ticks in whole milliseconds. The underlying clock is the best available system clock, equivalent to using system(ZoneId).
...
Since:
9
3
In other words, resolution of current moment is an implementation detail.
– Basil Bourque
Aug 26 '18 at 21:52
add a comment |
I don’t think you can get any better precision than the one you are already getting. If you want to reduce the precision to match that of the other system, it’s straightforward (when you know how):
LocalDateTime.now(ZoneId.of("Europe/Berlin")).truncatedTo(ChronoUnit.MILLIS);
The precision you get depends on the hardware, the settings, the OS and the integration of the JVM with all of those. It’s well known that Mac generally offers better precision than Windows (though I was under the impression that this was only the case from Java 9, per OpenJDK issue # JDK‑8068730).
2
is ZoneID needed? maybe a bit confusing, at least it is kind of hiding the important part (laptop)
– Carlos Heuberger
Aug 26 '18 at 20:34
6
A good habit if you want to control what you get, @CarlosHeuberger. If you want the JVM’s default time zone in that moment, I still preferZoneId.systemDefault()
over leaving it out. It reads the intention more clearly, though the result is the same. You are correct that this discussion is not relevant to the question asked.
– Ole V.V.
Aug 26 '18 at 20:36
3
sure, there are a lot of 'good habits'... like having a constant for such? like avoiding too long lines?
– Carlos Heuberger
Aug 26 '18 at 20:41
add a comment |
Your Answer
StackExchange.ifUsing("editor", function ()
StackExchange.using("externalEditor", function ()
StackExchange.using("snippets", function ()
StackExchange.snippets.init();
);
);
, "code-snippets");
StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "1"
;
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function()
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled)
StackExchange.using("snippets", function()
createEditor();
);
else
createEditor();
);
function createEditor()
StackExchange.prepareEditor(
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader:
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
,
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
);
);
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f52029920%2flocaldatetime-now-has-different-levels-of-precision-on-windows-and-mac-machine%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
The precision is different because LocalDateTime.now()
uses a system default Clock
.
Obtains the current date-time from the system clock in the default time-zone.
This will query the system clock in the default time-zone to obtain the current date-time.
...
The link in this Javadoc takes you to Clock.systemDefaultZone()
which states (emphasis mine):
Obtains a clock that returns the current instant using the best available system clock, converting to date and time using the default time-zone.
This clock is based on the best available system clock. This may use System.currentTimeMillis(), or a higher resolution clock if one is available.
...
Which clock Java uses can depend on a lot of things and it looks like your Mac computer has a clock with microsecond precision whereas your Windows computer has a clock with millisecond precision. I'm not aware of any way to increase the precision of a clock but you can definitely decrease the precision so that it matches across platforms.
One option is to do as Ole V.V. does in his answer and use LocalDateTime.truncatedTo(TemporalUnit)
.
Another option is to plug in your own Clock
and use LocalDateTime.now(Clock)
. If possible, I would use Clock.tickMillis(ZoneId)
since this method returns a Clock
that truncates to milliseconds.
Obtains a clock that returns the current instant ticking in whole milliseconds using the best available system clock.
This clock will always have the nano-of-second field truncated to milliseconds. This ensures that the visible time ticks in whole milliseconds. The underlying clock is the best available system clock, equivalent to using system(ZoneId).
...
Since:
9
3
In other words, resolution of current moment is an implementation detail.
– Basil Bourque
Aug 26 '18 at 21:52
add a comment |
The precision is different because LocalDateTime.now()
uses a system default Clock
.
Obtains the current date-time from the system clock in the default time-zone.
This will query the system clock in the default time-zone to obtain the current date-time.
...
The link in this Javadoc takes you to Clock.systemDefaultZone()
which states (emphasis mine):
Obtains a clock that returns the current instant using the best available system clock, converting to date and time using the default time-zone.
This clock is based on the best available system clock. This may use System.currentTimeMillis(), or a higher resolution clock if one is available.
...
Which clock Java uses can depend on a lot of things and it looks like your Mac computer has a clock with microsecond precision whereas your Windows computer has a clock with millisecond precision. I'm not aware of any way to increase the precision of a clock but you can definitely decrease the precision so that it matches across platforms.
One option is to do as Ole V.V. does in his answer and use LocalDateTime.truncatedTo(TemporalUnit)
.
Another option is to plug in your own Clock
and use LocalDateTime.now(Clock)
. If possible, I would use Clock.tickMillis(ZoneId)
since this method returns a Clock
that truncates to milliseconds.
Obtains a clock that returns the current instant ticking in whole milliseconds using the best available system clock.
This clock will always have the nano-of-second field truncated to milliseconds. This ensures that the visible time ticks in whole milliseconds. The underlying clock is the best available system clock, equivalent to using system(ZoneId).
...
Since:
9
3
In other words, resolution of current moment is an implementation detail.
– Basil Bourque
Aug 26 '18 at 21:52
add a comment |
The precision is different because LocalDateTime.now()
uses a system default Clock
.
Obtains the current date-time from the system clock in the default time-zone.
This will query the system clock in the default time-zone to obtain the current date-time.
...
The link in this Javadoc takes you to Clock.systemDefaultZone()
which states (emphasis mine):
Obtains a clock that returns the current instant using the best available system clock, converting to date and time using the default time-zone.
This clock is based on the best available system clock. This may use System.currentTimeMillis(), or a higher resolution clock if one is available.
...
Which clock Java uses can depend on a lot of things and it looks like your Mac computer has a clock with microsecond precision whereas your Windows computer has a clock with millisecond precision. I'm not aware of any way to increase the precision of a clock but you can definitely decrease the precision so that it matches across platforms.
One option is to do as Ole V.V. does in his answer and use LocalDateTime.truncatedTo(TemporalUnit)
.
Another option is to plug in your own Clock
and use LocalDateTime.now(Clock)
. If possible, I would use Clock.tickMillis(ZoneId)
since this method returns a Clock
that truncates to milliseconds.
Obtains a clock that returns the current instant ticking in whole milliseconds using the best available system clock.
This clock will always have the nano-of-second field truncated to milliseconds. This ensures that the visible time ticks in whole milliseconds. The underlying clock is the best available system clock, equivalent to using system(ZoneId).
...
Since:
9
The precision is different because LocalDateTime.now()
uses a system default Clock
.
Obtains the current date-time from the system clock in the default time-zone.
This will query the system clock in the default time-zone to obtain the current date-time.
...
The link in this Javadoc takes you to Clock.systemDefaultZone()
which states (emphasis mine):
Obtains a clock that returns the current instant using the best available system clock, converting to date and time using the default time-zone.
This clock is based on the best available system clock. This may use System.currentTimeMillis(), or a higher resolution clock if one is available.
...
Which clock Java uses can depend on a lot of things and it looks like your Mac computer has a clock with microsecond precision whereas your Windows computer has a clock with millisecond precision. I'm not aware of any way to increase the precision of a clock but you can definitely decrease the precision so that it matches across platforms.
One option is to do as Ole V.V. does in his answer and use LocalDateTime.truncatedTo(TemporalUnit)
.
Another option is to plug in your own Clock
and use LocalDateTime.now(Clock)
. If possible, I would use Clock.tickMillis(ZoneId)
since this method returns a Clock
that truncates to milliseconds.
Obtains a clock that returns the current instant ticking in whole milliseconds using the best available system clock.
This clock will always have the nano-of-second field truncated to milliseconds. This ensures that the visible time ticks in whole milliseconds. The underlying clock is the best available system clock, equivalent to using system(ZoneId).
...
Since:
9
edited Aug 27 '18 at 0:52
answered Aug 26 '18 at 20:49
SlawSlaw
8,38631033
8,38631033
3
In other words, resolution of current moment is an implementation detail.
– Basil Bourque
Aug 26 '18 at 21:52
add a comment |
3
In other words, resolution of current moment is an implementation detail.
– Basil Bourque
Aug 26 '18 at 21:52
3
3
In other words, resolution of current moment is an implementation detail.
– Basil Bourque
Aug 26 '18 at 21:52
In other words, resolution of current moment is an implementation detail.
– Basil Bourque
Aug 26 '18 at 21:52
add a comment |
I don’t think you can get any better precision than the one you are already getting. If you want to reduce the precision to match that of the other system, it’s straightforward (when you know how):
LocalDateTime.now(ZoneId.of("Europe/Berlin")).truncatedTo(ChronoUnit.MILLIS);
The precision you get depends on the hardware, the settings, the OS and the integration of the JVM with all of those. It’s well known that Mac generally offers better precision than Windows (though I was under the impression that this was only the case from Java 9, per OpenJDK issue # JDK‑8068730).
2
is ZoneID needed? maybe a bit confusing, at least it is kind of hiding the important part (laptop)
– Carlos Heuberger
Aug 26 '18 at 20:34
6
A good habit if you want to control what you get, @CarlosHeuberger. If you want the JVM’s default time zone in that moment, I still preferZoneId.systemDefault()
over leaving it out. It reads the intention more clearly, though the result is the same. You are correct that this discussion is not relevant to the question asked.
– Ole V.V.
Aug 26 '18 at 20:36
3
sure, there are a lot of 'good habits'... like having a constant for such? like avoiding too long lines?
– Carlos Heuberger
Aug 26 '18 at 20:41
add a comment |
I don’t think you can get any better precision than the one you are already getting. If you want to reduce the precision to match that of the other system, it’s straightforward (when you know how):
LocalDateTime.now(ZoneId.of("Europe/Berlin")).truncatedTo(ChronoUnit.MILLIS);
The precision you get depends on the hardware, the settings, the OS and the integration of the JVM with all of those. It’s well known that Mac generally offers better precision than Windows (though I was under the impression that this was only the case from Java 9, per OpenJDK issue # JDK‑8068730).
2
is ZoneID needed? maybe a bit confusing, at least it is kind of hiding the important part (laptop)
– Carlos Heuberger
Aug 26 '18 at 20:34
6
A good habit if you want to control what you get, @CarlosHeuberger. If you want the JVM’s default time zone in that moment, I still preferZoneId.systemDefault()
over leaving it out. It reads the intention more clearly, though the result is the same. You are correct that this discussion is not relevant to the question asked.
– Ole V.V.
Aug 26 '18 at 20:36
3
sure, there are a lot of 'good habits'... like having a constant for such? like avoiding too long lines?
– Carlos Heuberger
Aug 26 '18 at 20:41
add a comment |
I don’t think you can get any better precision than the one you are already getting. If you want to reduce the precision to match that of the other system, it’s straightforward (when you know how):
LocalDateTime.now(ZoneId.of("Europe/Berlin")).truncatedTo(ChronoUnit.MILLIS);
The precision you get depends on the hardware, the settings, the OS and the integration of the JVM with all of those. It’s well known that Mac generally offers better precision than Windows (though I was under the impression that this was only the case from Java 9, per OpenJDK issue # JDK‑8068730).
I don’t think you can get any better precision than the one you are already getting. If you want to reduce the precision to match that of the other system, it’s straightforward (when you know how):
LocalDateTime.now(ZoneId.of("Europe/Berlin")).truncatedTo(ChronoUnit.MILLIS);
The precision you get depends on the hardware, the settings, the OS and the integration of the JVM with all of those. It’s well known that Mac generally offers better precision than Windows (though I was under the impression that this was only the case from Java 9, per OpenJDK issue # JDK‑8068730).
edited Aug 26 '18 at 21:48
Basil Bourque
111k28383543
111k28383543
answered Aug 26 '18 at 20:30
Ole V.V.Ole V.V.
29.3k63653
29.3k63653
2
is ZoneID needed? maybe a bit confusing, at least it is kind of hiding the important part (laptop)
– Carlos Heuberger
Aug 26 '18 at 20:34
6
A good habit if you want to control what you get, @CarlosHeuberger. If you want the JVM’s default time zone in that moment, I still preferZoneId.systemDefault()
over leaving it out. It reads the intention more clearly, though the result is the same. You are correct that this discussion is not relevant to the question asked.
– Ole V.V.
Aug 26 '18 at 20:36
3
sure, there are a lot of 'good habits'... like having a constant for such? like avoiding too long lines?
– Carlos Heuberger
Aug 26 '18 at 20:41
add a comment |
2
is ZoneID needed? maybe a bit confusing, at least it is kind of hiding the important part (laptop)
– Carlos Heuberger
Aug 26 '18 at 20:34
6
A good habit if you want to control what you get, @CarlosHeuberger. If you want the JVM’s default time zone in that moment, I still preferZoneId.systemDefault()
over leaving it out. It reads the intention more clearly, though the result is the same. You are correct that this discussion is not relevant to the question asked.
– Ole V.V.
Aug 26 '18 at 20:36
3
sure, there are a lot of 'good habits'... like having a constant for such? like avoiding too long lines?
– Carlos Heuberger
Aug 26 '18 at 20:41
2
2
is ZoneID needed? maybe a bit confusing, at least it is kind of hiding the important part (laptop)
– Carlos Heuberger
Aug 26 '18 at 20:34
is ZoneID needed? maybe a bit confusing, at least it is kind of hiding the important part (laptop)
– Carlos Heuberger
Aug 26 '18 at 20:34
6
6
A good habit if you want to control what you get, @CarlosHeuberger. If you want the JVM’s default time zone in that moment, I still prefer
ZoneId.systemDefault()
over leaving it out. It reads the intention more clearly, though the result is the same. You are correct that this discussion is not relevant to the question asked.– Ole V.V.
Aug 26 '18 at 20:36
A good habit if you want to control what you get, @CarlosHeuberger. If you want the JVM’s default time zone in that moment, I still prefer
ZoneId.systemDefault()
over leaving it out. It reads the intention more clearly, though the result is the same. You are correct that this discussion is not relevant to the question asked.– Ole V.V.
Aug 26 '18 at 20:36
3
3
sure, there are a lot of 'good habits'... like having a constant for such? like avoiding too long lines?
– Carlos Heuberger
Aug 26 '18 at 20:41
sure, there are a lot of 'good habits'... like having a constant for such? like avoiding too long lines?
– Carlos Heuberger
Aug 26 '18 at 20:41
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f52029920%2flocaldatetime-now-has-different-levels-of-precision-on-windows-and-mac-machine%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
1
LocalDateTime.now()
uses the systemClock
which means whatever precision the system clock has that's how much precisionLocalDateTime.now()
will have.– Slaw
Aug 26 '18 at 20:18
"milliseconds precision of 6" is that the same as microsecond precision? (Perhaps better phrased as "subsecond precision").
– Andy Turner
Aug 26 '18 at 20:18
Sorry! It´s actually called "nano".
– Tobias Marschall
Aug 26 '18 at 20:21
@Slaw Running
System.currentTimeMillis()
provides the same level of precision on both machines.– Tobias Marschall
Aug 26 '18 at 20:23
5
The system
Clock
may useSystem.currentTimeMillis()
or a higher resolution clock if available. It looks like your Mac has a clock with microsecond precision.– Slaw
Aug 26 '18 at 20:28