Disable an FTP test which contains a date with year 2079 due to year-2038 problem on Linux.

Disable an FTP test which contains a date with year 2079 due to year-2038 problem on Linux.

The date wraps around then and gives nonsensical results (the field to store the timestamp
is too short to store dates beyond year 2038).

TBR=wtc

TEST=none
BUG=25520
Committed: http://src.chromium.org/viewvc/chrome?view=rev&revision=31378

[Paweł Hajdan Jr., 2009-11-07 09:21:32]

TBR

I consider this only a temporary "solution". Do you have an idea how to properly
fix that?

[wtc, 2009-11-07 15:33:59]

LGTM.

We have several options.

1. Disable the test for 32-bit Linux.

2. Use a different expected test result for 32-bit Linux.
Note that the timestamp doesn't wrap around.  Rather,
it "saturates" at INT_MAX, which is some time in year
2038.  Use that as the expected test result for 32-bit
Linux.

3. On Linux, call the PR_ParseTimeString from the
system NSPR library, which doesn't have the year
2038 issue.  NSS (which we use for SSL) requires
NSPR, so this won't add a new dependency on NSPR.

4. Replace our OS-specific implementations of the
PR_ImplodeTime function in src/base/third_party/nspr/prtime.cc
with the PR_ImplodeTime code from NSPR upstream:
http://mxr.mozilla.org/nspr/source/nsprpub/pr/src/misc/prtime.c#261
Although this is only necessary for Linux, I'd replace
all OS-specific implementations for simplicity, at the
cost of adding some code.

I recommend that we do 1 or 2 immediately, and
then do 4.  I'm open to doing 3 instead of 4,
or replacing only the Linux implementation of
PR_ImplodeTime.