poi-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Uwe Schindler" <...@thetaphi.de>
Subject RE: Time Zone Setting
Date Thu, 03 Sep 2015 14:25:59 GMT
Hi,

This may be only slightly related: to work around the forbidden-apis issue, you can still
pass Timezone.getDefault() to the Java APIs - this is not forbidden. Forbidden APIs just wants
to make sure you know what you are doing. By writing Timezone.getDefault() you explicitely
say what you are doing. And maybe add a comment why you do this. The same applies for Locales
or Charsets. E.g., At some places in Lucene we explicitely use the charset of the console,
so we use Charset.getDefault() at all those places.

Uwe

-----
Uwe Schindler
H.-H.-Meier-Allee 63, D-28213 Bremen
http://www.thetaphi.de
eMail: uwe@thetaphi.de


> -----Original Message-----
> From: Dominik Stadler [mailto:dominik.stadler@gmx.at]
> Sent: Thursday, September 03, 2015 4:05 PM
> To: POI Developers List
> Subject: Re: Time Zone Setting
> 
> 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 <kiwiwings@apache.org>
> 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: dev-unsubscribe@poi.apache.org For additional
> > commands, e-mail: dev-help@poi.apache.org
> >
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@poi.apache.org For additional
> commands, e-mail: dev-help@poi.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@poi.apache.org
For additional commands, e-mail: dev-help@poi.apache.org


Mime
View raw message