tstamp testMagicProperty consistently failing on Windows

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

tstamp testMagicProperty consistently failing on Windows

Jaikiran Pai-2
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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: tstamp testMagicProperty consistently failing on Windows

Stefan Bodewig
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: [hidden email]
For additional commands, e-mail: [hidden email]