You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ant.apache.org by Jaikiran Pai <ja...@apache.org> on 2018/08/19 16:07:58 UTC
tstamp testMagicProperty consistently failing on Windows
The tstamp (antunit) test named "testMagicProperty" has been
consistently failing (only) on Windows for a while now[1]. Both master
and 1.9.x branches. The failure looks really odd and something that I
haven't been able to understand yet. The one interesting bit to this
failure, based on what I can find in the history, is that it fails only
on "windows-2016" node(s) but has passed (and still passes) on
"windows-2012" node(s).
Looking at the tstamp task code, I haven't yet found out what can lead
to this issue. The only way I can think of this happening is that the
number of seconds being added to the epoch is less than a day's value -
which isn't the case in that test case which adds 100000 seconds.
https://builds.apache.org/job/Ant-Build-Matrix-master-Windows/jdk=JDK%201.8.0_121%20(unlimited%20security)%2064-bit%20Windows%20only,label_exp=Windows/lastCompletedBuild/testReport/src.tests.antunit.taskdefs/tstamp-test_xml/testMagicProperty/
-Jaikiran
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: tstamp testMagicProperty consistently failing on Windows
Posted by Stefan Bodewig <bo...@apache.org>.
On 2018-08-19, Jaikiran Pai wrote:
> The tstamp (antunit) test named "testMagicProperty" has been
> consistently failing (only) on Windows for a while now[1]. Both master
> and 1.9.x branches. The failure looks really odd and something that I
> haven't been able to understand yet. The one interesting bit to this
> failure, based on what I can find in the history, is that it fails only
> on "windows-2016" node(s) but has passed (and still passes) on
> "windows-2012" node(s).
The timezones are different. The machine on which the tests pass is in
UTC, the one where they fail is in "America/Los_Angeles".
100000 seconds after the epoch may still be the first of January in that
timezone if its UTC offset is 4 hours or more before UTC (which it
probably is).
SimpleDateFormat seems to be using local time in some contexts, for
another hint see the discussion in https://github.com/apache/ant/pull/40
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org