Follow up to previous post, New Java 8 date/time classes: parsing to older classes, with Time Zone

Variable fraction digits

It turns out (I should have read the StackOverflow C# .NET link more carefully), not only can .NET omit milliseconds, it also truncates them down to the lowest number of necessary digits. And considers them a true decimal fraction, so that .47 means 470 ms.

After some wrestling and initial despair, the following actually seems to fully handle that, using the longer, more controlled form of creating a Formatter via a “Builder”:

    public static final DateTimeFormatter TZ_FORMATTER =  
        new DateTimeFormatterBuilder().appendPattern("yyyy-MM-dd'T'HH:mm:ss")  
                                      .appendFraction(ChronoField.MILLI_OF_SECOND, 0, 3, true)  
                                      .toFormatter()  
                                      .withZone(ZoneId.of("America/Phoenix"));

Which is 0-3 digits of milliseconds, with “true” for the decimal point.

See DateTimeFomatterBuilder.appendFraction().

Single-digit patterns

I had originally switched this pattern to use single-character Month, day, Hours, minutes, seconds, since the 2-character ones require 2 digits. (Unlike java.text.SimpleDateFormat.) But it turns out that .NET does always send and want 2 digits.