Create a DateTimeFormater with an Optional Section at Beginning

I started to suspect that 20:33.123 wasn’t meant to indicate a time of day between 20 and 21 minutes past midnight. Maybe rather an amount of time, a little longer than 20 minutes. If this is correct, use a Duration for it.

Unfortunately java.time does not include means for parsing and formatting a Duration in other than ISO 8601 format. This leaves us with at least three options:

1. Use a third-party library. Time4J offers an elegant solution, see below. Joda-Time has its PeriodFormatter class. Apache may also offer facilities for parsing and formatting of durations.
2. Convert your string to ISO 8601 format before parsing with Duration.parse().
3. Write your own parser.

I was thinking that we’re too lazy for 3. and that Joda-Time is getting dated, so I want to pursue options 1. and 2. here, option 1. in the Time4J variant.

A regex for adapting to ISO 8601

ISO 8601 format for a duration feels unusual at first, but is straightforward. PT20M33.123S means 20 minutes 33.123 seconds.

public static Duration parse(String timeCodeString) {
    String iso8601 = timeCodeString
            .replaceFirst("^(\\d{2,}):(\\d{2}):(\\d{2}\\.\\d{3})$", "PT$1H$2M$3S")
            .replaceFirst("^(\\d{2}):(\\d{2}\\.\\d{3})$", "PT$1M$2S");
    return Duration.parse(iso8601);
}

Let’s try it out:

    System.out.println(parse("20:33.123"));
    System.out.println(parse("123:20:33.123"));

Output is:

PT20M33.123S
PT123H20M33.123S

My two calls to replaceFirst first handle the case with hours, then the case without hours. So either will convert a string that matches your regex to ISO 8601 format. Which the Duration class then parses. And as you can see, Duration also prints ISO 8601 format back. Formatting it differently is not bad, though, search for how.

Time4J

The Time4J library offers the really elegant solution very much along the same line of thought as yours. All we really need is this formatter:

private static final Formatter<ClockUnit> TIME_CODE_PARSER 
        = Duration.formatter(ClockUnit.class, "[###hh:mm:ss.fff][mm:ss.fff]");

Simply use like this:

    System.out.println(TIME_CODE_PARSER.parse("20:33.123"));
    System.out.println(TIME_CODE_PARSER.parse("123:20:33.123"));

PT20M33,123000000S
PT123H20M33,123000000S

The Time4J Duration class too prints ISO 8601 format. It appears that it uses comma as decimal separator as is preferred in ISO 8601, and that it prints 9 decimals on the seconds also when some of them are 0.

In the format pattern string ###hh means 2 to 5 digit hours, and fff means three digits of decimal fraction of second.

Anything wrong with your approach?

Was there anything wrong with your approach? ChronoField.HOUR_OF_DAY means that: hour of day. 0 is midnight, 12 is noon and 23 is near the end of the day. This is not what you want, so yes, you are using the wrong means. While you can probably get it to work, anyone maintaining your code after you will find it confusing and will probably have a hard time making modification in line with your intentions.

Links

• Wikipedia article: ISO 8601
• Joda-Time PeriodFormatter
• Time4J TimeSpanFormatter

Try with two optional parts (one with hours, other without) like in:

var formatter = new DateTimeFormatterBuilder()
    .optionalStart()
      .appendValue(HOUR_OF_DAY, 2, 4, SignStyle.NEVER).appendLiteral(":")
      .appendValue(MINUTE_OF_HOUR, 2).appendLiteral(":")
      .appendValue(SECOND_OF_MINUTE, 2)
    .optionalEnd()
    .optionalStart()
      .parseDefaulting(HOUR_OF_DAY, 0)
      .appendValue(MINUTE_OF_HOUR, 2).appendLiteral(":")
      .appendValue(SECOND_OF_MINUTE, 2)
    .optionalEnd()
    .toFormatter(Locale.ENGLISH);

_{I do not know about TimecodeHour, so I used HOUR_OF_DAY to test}
^{(also too lazy to include fractions)}

I think fundamentally the problem is that it gets stuck going down the wrong path. It sees a field of length 2, which we know is the minutes but it believes is the hours. Once it believes the optional section is present, when we know it's not, the whole thing is destined to fail.

This is provable by changing the minimum hour length to 3.

.appendValue(TimecodeHour.HOUR, 3, 4, SignStyle.NEVER)

It now knows that the "20" cannot be hours, since hours requires at least 3 digits. With this small change, it now parses correctly, whether the optional section is present or not.

So presuming that the hours field really does need to be between 2 and 4 digits, I think you're stuck with having to implement a workaround. For example, count the number of colons in the string and use a different formatter depending on which one you run into. Using a different delimiter besides a colon for the hours would also work.

The parser logic has undergone quite a few bug fixes over the various Java versions since it was introduced - as you can imagine, there are so many potential edge cases - so I was hopeful using a recent version of Java would make this problem disappear. Unfortunately, it seems even in Java 16, the behaviour is still the same.