GH-1311: Use Locale.ROOT when formatting JDBC interval strings

[Arawoof06]

What's Changed

formatIntervalYear and formatIntervalDay build the Oracle-style interval strings the JDBC interval accessor returns from getString()/getObject() with String.format and no explicit locale, so java.util.Formatter renders the %d digits using the JVM default locale. On a JVM whose default locale uses non-ASCII digits (ar-EG, bn-BD, mr-IN, ...) an interval comes back as +٠٢١-٠٢ instead of +021-02, which corrupts the value handed to JDBC clients and breaks anything parsing it as ASCII. Pass Locale.ROOT to both calls, the same fix GH-1300 applied to the C Data Interface format strings.

Closes #1311.

[jbonofre]

LGTM.

Using Locale.ROOT in formatInternalYear and formatIntervalDay is the right fix, since %d otherwise follows the default locale and can emit non-ASCII digits (e.g. ar-EG). The new test covers that case, and the expected values (+021-02, +001 18:25:16.766) check out.

Nit (non blocking): testFormatIntervalIgnoresDefaultLocale calls Locale.setDefault, which is JVM-global. It restores the locale in finally, so this is only a concern if JUnit parallel execution is enabled for this module. If it is, consider @ResourceLock(Resources.LOCALE).