Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ


Choose your language

InfoQ Homepage News Date and Time Formatting in Java 9 Will Get Closer to Unicode Locale Standards

Date and Time Formatting in Java 9 Will Get Closer to Unicode Locale Standards

Leia em Português

This item in japanese

A number of parsing and formatting changes have been incorporated in Java 9 to bring the functionality closer to Unicode Locale Data Markup Language (LDML). These changes have been supervised by Stephen Colebourne, creator of the popular date-time library JodaTime, precursor of the new java.time component in Java 8. Abiding by the Unicode standard will provide better interoperability with other non-Java systems.

LDML is the language used by the Unicode Common Locale Data Repository (CLDR), a project of the Unicode Consortium to gather and store locale data from different parts of the world, enabling application developers to better adapt their programs to different cultures. Among other things, LDML deals with dates, times, and timezones, and more particularly with date formatting and parsing. The following is an extract of new features coming in Java 9 that bring java.time closer to the LDML specification:

  • JDK-8148947, DateTimeFormatter pattern letter ‘g’: the letter ‘g’, as specified in LDML, indicates a “Modified Julian day”; this is different from a normal Julian day in the sense that a) it depends on local time, rather than GMT, and b) it demarcates days at midnight, as opposed to noon.
  • JDK-8155823, Add date-time patterns 'v' and 'vvvv’: ‘v’ and ‘vvvv’ are LDML formats to indicate “generic non-location format”, e.g. “Pacific Time”, as opposed to the “generic location format” with specifies a city, like “Los Angeles Time”.
  • JDK-8148949, DateTimeFormatter pattern letters ‘A’, ’n’, ’N’: although LDML doesn’t specify formats ’n’ and ’N’, it does specify ‘A’, but the current behaviour in Java doesn’t match that of the spec. ‘A’ is meant to represent the total number of milliseconds elapsed in the day, with variable width, but currently Java treats this as fixed with: if ‘AA’ is specified as a pattern, it will fail to parse any value that is further than 99 milliseconds in the day. ’n’ and ’N’ are just Java extensions to the standard to represent nanoseconds within the second, and nanoseconds within the day, respectively.
  • JDK-8079628, java.time DateTimeFormatter containing "DD" fails on three-digit day-of-year value: similar to the previous problem, but with ‘D’ representing days within a year. If one specifies “DD” as a pattern, it will fail to parse “123” as the 123th day of the year.

As previously mentioned, a better alignment with the LDML will ease interoperability across systems, since there are multiple technologies that have adopted the LDML to some degree. Microsoft .NET uses LDML for general interexchange of locale data, and there are packages available for Node.js and Ruby, just to mention a few.

Rate this Article