Hi Benedikt!
----- Original Message -----
> From: Benedikt Ritter <brit...@apache.org>
> To: Commons Developers List <dev@commons.apache.org>
> Cc:
> Sent: Wednesday, January 8, 2014 4:26 PM
> Subject: Re: [lang] Failing tests in lang/trunk due to time zone
>
> Hello Bruno,
>
>
> 2014/1/8 Bruno P. Kinoshita <brunodepau...@yahoo.com.br>
>
>> Hi all,
>>
>> LANG-942 and LANG-943 were related to tests failing due to time zones. The
>> latter is related to a specific time zone (America/Sao_Paulo), and only
>> happens in my environment because it is using the day that DST started in
>> 2005.
>>
>> For the sake of curiosity, I set up a Jenkins job to build commons-lang
>> from the trunk and `mvn clean test -e -X -Duser.timezone=${timezone}`
> for
>> each given time zone (it is a multi config job with a user axis, fwiw).
>>
>> The results can be seen here:
>>
> http://builds.tupilabs.com/view/Apache%20Software%20Foundation/job/commons-lang-timezone/
>
>
> Thanks again for digging into this! You're becoming the commons TimeZone
> expert ;-)
I'm far from being any kind of expert, but thanks :)
> Maybe it makes sense to port your test to the apache jenkins instance? Do
> you have karma to do that?
I don't believe I have karma for that, but if there are a few idle slaves
there,
maybe someone could set up a similar job that would be triggered only before
new release
votes. The job configuration can be accessed freely from the Internet without
login.
Furthermore, perhaps we could set up a simple job with a few different JDK's as
well?
This way the RM could trigger it before calling the vote.
>>
>>
>> There are many different errors, inclusive for time zones within Brazil
>> that work (America/Maceio, while America/Sao_Paulo fails) and others in
>> Asia, Australia, Mexico, etc).
>>
>> I think some tests can be rewritten to be time zone agnostic, or we may
>> have some hidden bug too.
>
>
>> Just food for thought :^) not a blocker for new releases I think. The job
>> took quite some time to finish, but the URL is parameterized, so in the
>> future I plan to run it against tags and for different JDK's too.
>>
>
> I've thought about it. Since this doesn't seem to be a regression that
> has
> been introduced by 3.2, I won't delay 3.2.1 to fix this. But we definitely
> have to work on this for the next release.
>
+1
>>
>> Bruno P. Kinoshita
>> http://kinoshita.eti.br
>> http://tupilabs.com
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> For additional commands, e-mail: dev-h...@commons.apache.org
>>
>>
>
>
> --
> http://people.apache.org/~britter/
> http://www.systemoutprintln.de/
> http://twitter.com/BenediktRitter
> http://github.com/britter
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
