java-time

DateTimeFormatterBuilder with specified parseDefaulting conflicts for YEAR field

匆匆过客 提交于 2019-12-04 02:01:40
I have the following formatter: DateTimeFormatter formatter = new DateTimeFormatterBuilder() .appendPattern("yyyyMM") .parseDefaulting(ChronoField.SECOND_OF_MINUTE, 0) .parseDefaulting(ChronoField.MINUTE_OF_HOUR, 0) .parseDefaulting(ChronoField.HOUR_OF_DAY, 0) .parseDefaulting(ChronoField.DAY_OF_MONTH, 1) .parseDefaulting(ChronoField.MONTH_OF_YEAR, 1) .parseDefaulting(ChronoField.YEAR, ZonedDateTime.now().getYear()) .toFormatter() .withZone(ZoneId.systemDefault()); I try to parse the string "201505" System.out.println(ZonedDateTime.parse("201505", formatter)); and it throws an exception:

What is the difference of using TemporalAmount or TemporalUnit in Java 8?

前提是你 提交于 2019-12-04 01:35:45
I write some piece of code in Java 8 which use time arithmetic. I realize that I can implement in differentways. Lets look at simple code below. Of course it is the same result but I confused which way is mostly applied or most efficient to make arithmetic operations in Java 8 ? LocalTime time = LocalTime.now(); // 1st way LocalTime plusOp = time.plus(Duration.ofMinutes(10L)); // 2nd way LocalTime plusOp2 = time.plus(10L, ChronoUnit.MINUTES); System.out.println(plusOp); System.out.println(plusOp2); // 3. way simply time.plusMinutes(10L); Thanks in advance. Duration can only handle fixed-length

java.time equivalent of Joda-Time `withTimeAtStartOfDay`? (get first moment of the day)

寵の児 提交于 2019-12-04 00:58:51
In the Joda-Time library, the DateTime class offers a method withTimeAtStartOfDay to get the first moment of the day. You might think of that moment as "midnight". That first moment is usually the time 00:00:00.000 but not always. Does the java.time package found in Java 8 and later have an equivalent feature? Meno Hochschild The equivalent is using a special method, atStartOfDay , in the class LocalDate : ZoneId zoneId = ZoneId.of("America/New_York"); ZonedDateTime zdt = LocalDate.now(zoneId).atStartOfDay(zoneId); Please also note that the equivalent of Joda-Time DateTime is not LocalDateTime

TZupdater failing with tzdata2016g release

六月ゝ 毕业季﹏ 提交于 2019-12-04 00:32:31
问题 TZUpdater 2.1.0 is failing with tzdata2016g release. For Java 8 it fails with "Source directory does not contain file: VERSION" error, while it completes with "JRE updated to version : tzdataunknown" comment for Java 7. The reason of this seems to be recent change of IANA tzdata distribution: Unsetting VERSION field of Makefile. There is a bug reported regarding the issue: https://bugs.openjdk.java.net/browse/JDK-8166928. DST date(30th October 2016) is getting closer and we at least need a

java.time ISO date format with fixed millis digits (in Java 8 and later)

你。 提交于 2019-12-04 00:05:35
By default, the toString method of Instant uses the DateTimeFormatter.ISO_INSTANT formatter. That formatter won’t print the digits for fraction-of-second if they happen to be 0. java-time examples: 2015-10-08T17:13:07.589Z 2015-10-08T17:13:07Z Joda-Time examples (and what I'd expect from java.time): 2015-10-08T17:13:07.589Z 2015-10-08T17:13:07.000Z This is really frustrating to parse in some systems. Elasticsearch was the first problem I encountered, there's no pre-defined format that supports optional millis, but I can probably work around that with a custom format. The default just seems

Lenient Java 8 Date parsing

人盡茶涼 提交于 2019-12-03 18:04:00
问题 I'd like to parse '2015-10-01' with LocalDateTime . What I have to do is LocalDate localDate = LocalDate.parse('2015-10-01'); LocalDateTime localDateTime = localDateTime.of(localDate, LocalTime.MIN); But I'd like to parse it in one pass like // throws DateTimeParseException LocalDateTime date = LocalDateTime.parse('2015-10-01', DateTimeFormatter.ISO_LOCAL_DATE); Also a small difference of a string throws the exception as well. // throws DateTimeParseException LocalDate localDate = LocalDate

Where are the Java 8 DateTimeFormatters constants defined?

試著忘記壹切 提交于 2019-12-03 16:24:28
I am looking at the DateTimeFormatter class and I was wondering where are the constants like "M" , "EEE" and "YY" etc are defined. More specifically there should be code like this somewhere given a ChronoField and TextStyle , it should return the DateTimeFormatter string snippet e.g. (ChronoField.MONTH_OF_YEAR, TextStyle.SHORT) should map to the string "MMM" After some source digging, I found out that these are pre-defined in a private static final Map , called FIELD_MAP , which is a member of the DateTimeFormatBuilder class: /** Map of letters to fields. */ private static final Map<Character,

How to parse non-standard month names with DateTimeFormatter

社会主义新天地 提交于 2019-12-03 12:35:15
I need to parse (German) dates that come in the following form: 10. Jan. 18:14 8. Feb. 19:02 1. Mär. 19:40 4. Apr. 18:55 2. Mai 21:55 5. Juni 08:25 5. Juli 20:09 1. Aug. 13:42 [...] As you can see, the month names are cut if the month has more than 4 characters. Even weirder, don't aks me why, the month of March is shortened to Mär. although the whole name is März . How can I parse this with java.time ? (The dates are formatted based on the localization of the android device that creates the list of dates. However, I'm not parsing it on Android) My approach was to create a DateTimeFormatter

Spring Boot issues serializing java.time.LocalDateTime with Jackson to return ISO-8601 JSON timestamps?

江枫思渺然 提交于 2019-12-03 10:41:35
I'm working on converting some models in a spring-boot REST API app to use java 8's java.time.LocalDateTime instead of joda's DateTime . I want the timestamps returned from API call to adhere to the ISO_8601 format. Motivation is to be forward compatible with Java 8's time ( more here ). The part that's proving difficult is when it comes to serialize an object containing LocalDateTime to JSON. For example, I have the following entity: // ... misc imports import java.time.LocalDateTime; import java.time.ZoneOffset; @Data @Entity @Table(name = "users") public class User { @Id @Column private

Extremely slow parsing of time zone with the new java.time API

亡梦爱人 提交于 2019-12-03 08:17:08
问题 I was just migrating a module from the old java dates to the new java.time API, and noticed a huge drop in performance. It boiled down to parsing of dates with timezone (I parse millions of them at a time). Parsing of date string without a time zone ( yyyy/MM/dd HH:mm:ss ) is fast - about 2 times faster than with the old java date, about 1.5M operations per second on my PC. However, when the pattern contains a time zone ( yyyy/MM/dd HH:mm:ss z ), the performance drops about 15 times with the