A cell format such as: [$-409]mmmm dd yyyy h:mm AM/PM should format explicitly in English. A cell format such as: [$-804]mmmm dd yyyy h:mm AM/PM should format in Chinese (although in an inappropriate order for Chinese.) When I do this using POI though, CellFormat.apply(double) or CellFormat.apply(Cell) throw NullPointerException for both formats.
Could you try with a recent nightly build / svn checkout? There was a fix for locales in formats a few weeks ago, which may have solved this too. If the problem still remains with a recent build, could you please post the full stacktrace, and ideally a unit test that highlights the problem?
Current trunk build seems to be broken. /Data/Projects/vendor/poi/trunk/build.xml:412: taskdef class org.apache.xmlbeans.impl.tool.XMLBean cannot be found using the classloader AntClassLoader[/Data/Projects/vendor/poi/trunk/ooxml-lib/xmlbeans-2.3.0.jar:/Data/Projects/vendor/poi/trunk/ooxml-lib/stax-api-1.0.1.jar] Searching on Google found a post which suggests that xmlbeans-2.3.0.jar might be corrupt. It is in fact corrupt, but after deleting it, another corrupt copy is downloaded the next time I run the build. :/
Could you perhaps have a broken webproxy in front of you, which is wrecking your downloads? I'd suggest you either download the jar manually, or download an older binary/source release and grab a known good jar out of that
Manually downloaded that file and another one which the build downloaded a corrupt copy of. And no, there is no web proxy in front of me at all. There might be one in front of the mirror server which the build is downloading from. Looks like the issue still occurs (same NullPointerException.)
Any chance of the full stacktrace so we can see where the NPE is triggered, and ideally also a unit test?
@Test public void testCellFormatDateLocales() throws Exception { CellFormat englishFormat = CellFormat.getInstance("[$-409]mmmm dd yyyy h:mm AM/PM"); assertThat(englishFormat.apply(26995.477777777778).text, is(equalTo("November 27 1973 11:28 AM"))); CellFormat chineseFormat = CellFormat.getInstance("[$-804]mmmm dd yyyy h:mm AM/PM"); assertThat(chineseFormat.apply(26995.477777777778).text, is(equalTo("\u5341\u4E00\u6708 27 1973 11:28 \u4E0A\u5348"))); } This should be enough to reproduce it. I'm not 100% sure if the expected text is exactly correct because I took this double value from the debugger while our own test was running and floating point often ruins precision...
Still occurs in 3.9, but the stack trace is different now, now the NPE is in CellFormat.getApplicableFormatPart(CellFormat.java:365)
Thanks for the test I've added a slightly modified form in r1614741, which shows that trunk is now able to parse these style of formats without error
We now get a different problem on the exact same test case we posted in the comment here, but I'll open a new ticket about it, since it at least isn't a NPE anymore.