Our project needs quarter support and unfortunately we are on java 1.7 and are stuck on it for unfortunate other reasons.
We added the ICU4j library to use the SimpleDateFormat provided within.
Unfortunately it is parsing dates very oddly (see below). Any help would be appreciated.
val formatter = new java.text.SimpleDateFormat("yyyy")
val formatter2 = new com.ibm.icu.text.SimpleDateFormat("yyyy")
Array(formatter2.parse("1234"), formatter.parse("1234"))
Result
0 = {Date@10561} "Sun Jan 01 00:00:00 PST 1234"
1 = {Date@10563} "Sun Jan 01 00:12:28 PST 1234"
I have read the docs extensively but not sure why it is parsing with an offset. I am sure that it's part of the api and hoping that someone can explain my difficulties. Any help would be appreciated.
http://www.icu-project.org/apiref/icu4j/com/ibm/icu/text/SimpleDateFormat.html
About timezone problem:
Probably the timezone data/rules of ICU4J and your Java-7-JVM are different for the year 1234. Normally you should use years after 1900, right? If so then the probability to get the same rules are much higher. If not then you should really care about choosing the right versions to ensure you have the same rules. Maybe you also need to apply the tzupdater-tool of Oracle.
Update about zones:
Thanks to the good research of OP, we can set a system property specific for ICU4J:
com.ibm.icu.util.TimeZone.DefaultTimeZoneType = JDK
Anyway, if the only reason to use ICU4J is support for quarter-years then an alternative might also be
either
using my library Time4J (v3.x-line runnable on Java-6+7). It also offers quarter support by a lower size and better API (nearer to what java.time in Java-8 does) including good internationalization based on same CLDR-data as ICU4J does, see also pattern doc
or
using the Threeten-Backport (with the disadvantage not to have any internationalization -> lack of localized data).