Hi, Sorry, but I fear that through this we change the default behavior of POI: * A ThreadLocal can lead to hard-to-find errors when people use POI in a multi-threading environment. While it is better in some cases than having a global static, it now requires the developer to ensure that the timezone is set for each thread that is started without a way to set it globally. * I think previously POI used the java default settings which look at the operating system, this is now broken as we have "UTC" as default, which potentially leads to many people seeing different results compared to before, in fact almost anybody would now see UTC-formatted dates instead of local timezone, or? * The java default is to either use the system default timezone or if it should be different then use -Duser.timezone when invoking the JRE, see e.g. http://stackoverflow.com/questions/2493749/how-to-set-a-jvm-timezone-properly
So my approach would be to: * Not use the DateUtil.setTimezone() approach as it has quite some potential for regressions but also not use TimeZone.setDefault() in unit tests at all * Ensure that we set -Duser.timezone to a fixed value when running unit tests in the various CI systems. We already do this for user.language and user.country, so setting the timezone as well here seems a natural choice This way we do not change default behavior for users and still make the CI runs a bit more reproducible time-wise... Dominik. On Wed, Sep 2, 2015 at 9:38 AM, Andreas Beeker <[email protected]> wrote: > Hi, > > in the code we have some places where we reset the default time zone [1], > like the following: > > TimeZone cet = TimeZone.getTimeZone("Europe/Copenhagen"); > TimeZone.setDefault(cet); > > Although this is just in a junit test, I don't think it's a good idea to set > the jdk default. > I've added a new ThreadLocal to DateUtil and although I'm not convinced, that > this > is a definite solution, at least it's pragmatical: > > @BeforeClass > public static void setTimeZone() { > userTimeZone = DateUtil.getUserTimeZone(); > DateUtil.setUserTimeZone(TimeZone.getTimeZone("CET")); > } > > Another solution would be, to guess the TimeZone by parsing date cells in the > workbook > and compare them to the stored string values ... of course this only applies > to X/HSLF. > > What do you think about it? > > Andi. > > > > [1] org.apache.poi.hssf.usermodel.TestHSSFDateUtil > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
