The problem is that there is a difference between what a ZoneId is and a ZoneOffset is. To create a OffsetDateTime, you need an zone offset. But there is no one-to-one mapping between a ZoneId and a ZoneOffset because it actually depends on the current daylight saving time. For the same ZoneId like “Europe/Berlin”, there … Read more
Getting a Calendar instant from ZonedDateTime is pretty straight-forward, provided you know that there exists a GregorianCalendar#from(ZonedDateTime) method. There was a discussion in Threeten-dev mail group, about why that method is not in Calendar class. Not a very deep discussion though. However, there is no direct way to convert from an Instant to Calendar. You’ve … Read more
Calling toInstant().toEpochMilli(), as suggested by @JB Nizet’s comment, is the right answer, but there’s a little and tricky detail about using local dates that you must be aware of. But before that, some other minor details: Instead of ZoneId.of(“GMT”) you can use the built-in constant ZoneOffset.UTC. They’re equivalent, but there’s no need to create extra … Read more
Solution was to add .configure(DeserializationFeature.READ_DATE_TIMESTAMPS_AS_NANOSECONDS, false) to the ObjectMapper. Complete ObjectMapper looks like: ObjectMapper om = new ObjectMapper() .registerModule(new JavaTimeModule()) .configure(SerializationFeature.WRITE_DATE_TIMESTAMPS_AS_NANOSECONDS, false) .configure(SerializationFeature.FAIL_ON_EMPTY_BEANS, false) .configure(DeserializationFeature.FAIL_ON_UNKNOWN_PROPERTIES, false) .configure(DeserializationFeature.READ_DATE_TIMESTAMPS_AS_NANOSECONDS, false) .setSerializationInclusion(Include.NON_NULL);
Most database vendors don’t support JDBC 4.2 yet. This specification says that the new java.time-types like LocalDate will/should be supported using the existing methods setObject(…) and getObject(). No explicit conversion is required and offered (no API-change). A workaround for the missing support can be manual conversion as described on the Derby-mailing list. Something like: LocalDate … Read more
As @the8472 says, the key is to have the time synchronization on the machine (where the jvm runs) correct. If you program a client then it really can be dangerous to rely on the system clocks. But for servers, there is a solution – you might want to consider using NTP with strict configuration. In … Read more
Edit: I should add that these are nanoseconds not milliseconds. I feel these answers don’t really answer the question using the Java 8 SE Date and Time API as intended. I believe the truncatedTo method is the solution here. LocalDateTime now = LocalDateTime.now(); System.out.println(“Pre-Truncate: ” + now); DateTimeFormatter dtf = DateTimeFormatter.ISO_DATE_TIME; System.out.println(“Post-Truncate: ” + now.truncatedTo(ChronoUnit.SECONDS).format(dtf)); … Read more
This solves the problem: DateTimeFormatter formatter = new DateTimeFormatterBuilder() .appendPattern(“yyyy-MM-dd HH:mm:ss”) .appendFraction(ChronoField.MICRO_OF_SECOND, 0, 6, true) .toFormatter(); System.out.println(LocalDateTime.parse(“2015-05-07 13:20:22.276052”, formatter)); System.out.println(LocalDateTime.parse(“2015-05-07 13:20:22.276”, formatter)); System.out.println(LocalDateTime.parse(“2015-05-07 13:20:22”, formatter)); // output 2015-05-07T13:20:22.276052 2015-05-07T13:20:22.276 2015-05-07T13:20:22 The answer by JiriS is incorrect, as it uses appendValue whereas the correct way is to use DateTimeFormatterBuilder.appendFraction (which also handles the decimal point). The … Read more
“stand-alone” month name I believe ‘L’ is meant for languages that use a different word for the month itself versus the way it is used in a date. For example: Locale russian = Locale.forLanguageTag(“ru”); asList(“MMMM”, “LLLL”).forEach(ptrn -> System.out.println(ptrn + “: ” + ofPattern(ptrn, russian).format(Month.MARCH)) ); Output: MMMM: марта LLLL: Март There shouldn’t be any reason … Read more
I believe it’s because the list of all possible timezones names can change regardless of Java version. Timezone information comes with Java installation (usually in the folder <java-home>/lib/zi, or in jre/lib/tzdb.dat file in newer versions). But this information can be updated without changing the Java version (using the Timezone Updater Tool). If the timezone data … Read more