java 8 日期/时间 API：使用通用日期/时间格式解析以提取自纪元以来的毫秒数

Question

Given any date/time format (passed by the user), I need to parse the date with it and return milliseconds since java epoch, something that could be done with the following code using old date API:

//dateFormatter is SimpleDateFormat
Date d = dateFormatter.parse(value);
return d.getTime();

The only requirement for the format that it will contain the date part, for example all of the following are possible formats:

"dd/MM/yyyy"
"dd/MM/yyyy HH:mm X" //with timezone

The missing part are completed with start of the day/local time zone. So I came up with the following, which seems to be much more verbose and not sure if there is a more efficient way to do it:

        //dateFormatter is DateTimeFormatter
        TemporalAccessor ta = dateFormatter.parse(value);
        
        LocalDate ld = LocalDate.from(ta); //assume must have date part

        LocalTime lt = ta.query(TemporalQueries.localTime());
        if (lt == null) {
            lt = LocalTime.MIN;
        }
        
        ZoneId zoneId = ta.query(TemporalQueries.zone());
        if (zoneId == null) {
            zoneId = ZoneId.systemDefault();
        }
        
        Instant d = LocalDateTime.of(ld, lt).atZone(zoneId).toInstant();
        return d.toEpochMilli();

Answer 1

Use DateTimeFormatterBuilder.parseDefaulting to set default values for when that field is not found in the format string:

DateTimeFormatter formatter = new DateTimeFormatterBuilder()
        .appendPattern(patternFromTheUser)
        // make everything non-required default to 0
        .parseDefaulting(ChronoField.HOUR_OF_DAY, 0)
        .parseDefaulting(ChronoField.MINUTE_OF_HOUR, 0)
        .parseDefaulting(ChronoField.SECOND_OF_MINUTE, 0)
        .parseDefaulting(ChronoField.OFFSET_SECONDS, 0)
        .toFormatter();
System.out.println(ZonedDateTime.parse("01/01/2021 20:00", formatter)
        .toInstant()
        .toEpochMilli());

Answer 2

As also shown in answer by Sweeper , you can specify default values in the formatter.

Zone ID is handled differently, where it is not just a default, it is also a kind of override, and has to be defined using withZone(ZoneId zone) after building the formatter.

If the format and value specifies a Zone ID, then it is used, all good. If it doesn't specify Zone ID or Zone Offset, the given "default" is used. However, if only Zone Offset is specified, it is used for parsing, but then the "default" Zone ID overrides the result, adjusting the time and Zone Offset accordingly.

Since you want epoch milliseconds, that doesn't actually affect this code, I just wanted to mention it for other users who might not do the final conversion to UTC.

The code should be:

public static long parseToEpochMillis(String format, String dateText) {
    return new DateTimeFormatterBuilder()
            .appendPattern(format)
            .parseDefaulting(ChronoField.HOUR_OF_DAY, 0)
            .toFormatter(Locale.US) // So e.g. MMM parses "Feb", not some other language
            .withZone(ZoneId.systemDefault())
            .parse(dateText, ZonedDateTime::from)
            .toInstant()
            .toEpochMilli();
}

Test

public static void main(String[] args) {
    test("M/d/u", "7/4/2015");
    test("M/d/u H:mm:ss VV", "7/4/2015 1:23:45 America/Denver");
    test("M/d/u H:mm:ssXXXXX", "7/4/2015 1:23:45-08:00");
    test("M/d/u H:mm:ssX", "7/4/2015 1:23:45Z");
}
static void test(String format, String dateText) {
    DateTimeFormatter formatter = new DateTimeFormatterBuilder()
            .appendPattern(format)
            .parseDefaulting(ChronoField.HOUR_OF_DAY, 0)
            .toFormatter(Locale.US)
            .withZone(ZoneId.systemDefault());
    ZonedDateTime dateTime = ZonedDateTime.parse(dateText, formatter);
    Instant instant = dateTime.toInstant();
    long epochMilli = instant.toEpochMilli();
    System.out.printf("%-45s -> %s -> %d%n", dateTime, instant, epochMilli);
}

Output

2015-07-04T00:00-04:00[America/New_York]      -> 2015-07-04T04:00:00Z -> 1435982400000
2015-07-04T01:23:45-06:00[America/Denver]     -> 2015-07-04T07:23:45Z -> 1435994625000
2015-07-04T05:23:45-04:00[America/New_York]   -> 2015-07-04T09:23:45Z -> 1436001825000
2015-07-03T21:23:45-04:00[America/New_York]   -> 2015-07-04T01:23:45Z -> 1435973025000