Description
A date cell formatted with Excel’s built-in short date format (numFmtId 14) is always rendered using the JVM default locale. The culture set with SpreadsheetLoadOptions.setCultureInfo() makes no difference.
Steps to reproduce
In a folder containing Repro.java, date.xlsx (both in Archiv.zip) and groupdocs-conversion-25.9.jar, run:
java -cp groupdocs-conversion-25.9.jar Repro.java
date.xlsx contains a single cell with the date 2026-09-17 in the built-in short date format. Repro.java sets the JVM default locale to en-US, converts the Excel file to PDF with setCultureInfo(new CultureInfo("de-CH")), and prints the text of the PDF.
Expected in CH Format: 17.09.2026
Actual in US Format: 9/17/2026
If de-CH is set as the JVM default locale instead, the output is 17.09.2026. So the date can be rendered in de-CH format. But setCultureInfo has no effect.
Changing the JVM default locale is no solution for us because it affects the whole VM.
public static void main(String... args) {
var xlsx = Path.of("date.xlsx");
var pdf = Path.of("date.pdf");
Locale.setDefault(Locale.US);
var loadOptions = new SpreadsheetLoadOptions();
loadOptions.setCultureInfo(new CultureInfo("de-CH")); // Has no effect
try (var converter = new Converter(xlsx.toString(), () -> loadOptions)) {
converter.convert(pdf.toString(), new PdfConvertOptions());
}
// Read the PDF back as plain text
System.out.println(toText(pdf));
}
private static String toText(Path pdf) {
var txt = new ByteArrayOutputStream();
try (var converter = new Converter(pdf.toString())) {
var toText = new WordProcessingConvertOptions();
toText.setFormat(WordProcessingFileType.Txt);
converter.convert(() -> txt, toText);
}
return txt.toString(StandardCharsets.UTF_8);
}