According to the SimpleDateFormat class documentation, Java
does not support time granularity above milliseconds in its date patterns.
So, a date string like
when parsed via the pattern
actually interprets the whole number after the .
symbol as (nearly 1 billion!) milliseconds and not as nanoseconds, resulting in the date
i.e. over 11 days ahead. Surprisingly, using a smaller number of S
symbols still results in all 9 digits being parsed (instead of, say, the leftmost 3 for .SSS
).
There are 2 ways to handle this issue correctly:
Would there be any other way for getting a correct solution by just supplying a pattern to the standard SimpleDateFormat
implementation, without any other code modifications or string manipulation?
ISO 8601 fractional minutes and hours are not supported. Typically, hosts support nanosecond timestamp resolution; excess precision is silently discarded.
ISO 8601 FormatsISO 8601 represents date and time by starting with the year, followed by the month, the day, the hour, the minutes, seconds and milliseconds. For example, 2020-07-10 15:00:00.000, represents the 10th of July 2020 at 3 p.m. (in local time as there is no time zone offset specified—more on that below).
You first need to convert your number representing nanoseconds to milliseconds. Then for the given date string, get the total number of milliseconds since the unix time Epoch, and then add the number earlier converted to milliseconds to it.
The epoch-seconds are measured from the standard Java epoch of 1970-01-01T00:00:00Z where instants after the epoch have positive values, and earlier instants have negative values. For both the epoch-second and nanosecond parts, a larger value is always later on the time-line than a smaller value.
LocalDateTime.parse( // With resolution of nanoseconds, represent the idea of a date and time somewhere, unspecified. Does *not* represent a moment, is *not* a point on the timeline. To determine an actual moment, place this date+time into context of a time zone (apply a `ZoneId` to get a `ZonedDateTime`). "2015-05-09 00:10:23.999750900" // A `String` nearly in standard ISO 8601 format. .replace( " " , "T" ) // Replace SPACE in middle with `T` to comply with ISO 8601 standard format. ) // Returns a `LocalDateTime` object.
No, you cannot use SimpleDateFormat to handle nanoseconds.
But your premise that…
Java does not support time granularity above milliseconds in its date patterns
…is no longer true as of Java 8, 9, 10 and later with java.time classes built-in. And not really true of Java 6 and Java 7 either, as most of the java.time functionality is back-ported.
SimpleDateFormat
, and the related java.util.Date
/.Calendar
classes are now outmoded by the new java.time package found in Java 8 (Tutorial).
The new java.time classes support nanosecond resolution. That support includes parsing and generating nine digits of fractional second. For example, when you use the java.time.format
DateTimeFormatter
API, the S
pattern letter denotes a "fraction of the second" rather than "milliseconds", and it can cope with nanosecond values.
Instant
As an example, the Instant
class represents a moment in UTC. Its toString
method generates a String
object using the standard ISO 8601 format. The Z
on the end means UTC, pronounced “Zulu”.
instant.toString() // Generate a `String` representing this moment, using standard ISO 8601 format.
2013-08-20T12:34:56.123456789Z
Note that capturing the current moment in Java 8 is limited to millisecond resolution. The java.time classes can hold a value in nanoseconds, but can only determine the current time with milliseconds. This limitation is due to the implementation of Clock
. In Java 9 and later, a new Clock
implementation can grab the current moment in finer resolution, depending on the limits of your host hardware and operating system, usually microseconds in my experience.
Instant instant = Instant.now() ; // Capture the current moment. May be in milliseconds or microseconds rather than the maximum resolution of nanoseconds.
LocalDateTime
Your example input string of 2015-05-09 00:10:23.999750900
lacks an indicator of time zone or offset-from-UTC. That means it does not represent a moment, is not a point on the timeline. Instead, it represents potential moments along a range of about 26-27 hours, the range of time zones around the globe.
Pares such an input as a LocalDateTime
object. First, replace the SPACE in the middle with a T
to comply with ISO 8601 format, used by default when parsing/generating strings. So no need to specify a formatting pattern.
LocalDateTime ldt = LocalDateTime.parse( "2015-05-09 00:10:23.999750900".replace( " " , "T" ) // Replace SPACE in middle with `T` to comply with ISO 8601 standard format. ) ;
java.sql.Timestamp
The java.sql.Timestamp
class also handles nanosecond resolution, but in an awkward way. Generally best to do your work inside java.time classes. No need to ever use Timestamp
again as of JDBC 4.2 and later.
myPreparedStatement.setObject( … , instant ) ;
And retrieval.
Instant instant = myResultSet.getObject( … , Instant.class ) ;
OffsetDateTime
Support for Instant
is not mandated by the JDBC specification, but OffsetDateTime
is. So if the above code fails with your JDBC driver, use the following.
OffsetDateTime odt = instant.atOffset( ZoneOffset.UTC ) ; myPreparedStatement.setObject( … , odt ) ;
And retrieval.
Instant instant = myResultSet.getObject( … , OffsetDateTime.class ).toInstant() ;
If using an older pre-4.2 JDBC driver, you can use toInstant
and from
methods to go back and forth between java.sql.Timestamp
and java.time. These new conversion methods were added to the old legacy classes.
The java.time framework is built into Java 8 and later. These classes supplant the troublesome old legacy date-time classes such as java.util.Date
, Calendar
, & SimpleDateFormat
.
The Joda-Time project, now in maintenance mode, advises migration to the java.time classes.
To learn more, see the Oracle Tutorial. And search Stack Overflow for many examples and explanations. Specification is JSR 310.
You may exchange java.time objects directly with your database. Use a JDBC driver compliant with JDBC 4.2 or later. No need for strings, no need for java.sql.*
classes.
Where to obtain the java.time classes?
The ThreeTen-Extra project extends java.time with additional classes. This project is a proving ground for possible future additions to java.time. You may find some useful classes here such as Interval
, YearWeek
, YearQuarter
, and more.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With