Fix JS seconds since epoch to date conversions.

Fix JS seconds since epoch to date conversions.

BUG=515137, 564736
R=ochang@chromium.org, tsepez@chromium.org

Committed: https://pdfium.googlesource.com/pdfium/+/b426e3edde040089b70d1a223c83b90957aa571d

[Lei Zhang, 2015-12-20 07:59:22]

thestig@chromium.org changed reviewers:
+ tsepez@chromium.org

[Tom Sepez, 2015-12-20 17:55:25]

Hmm. This just changes the initial estimate. Theoretically, we could replace
this with a call to say rand() and it would eventually converge, no? What am I
missing?

[Lei Zhang, 2015-12-20 22:03:34]

On 2015/12/20 17:55:25, Tom Sepez (ooo) wrote:
> Hmm. This just changes the initial estimate. Theoretically, we could replace
> this with a call to say rand() and it would eventually converge, no? What am I
> missing?

I fixed the convergence issue in patch set 2, but kept the more accurate year
estimate constant.

[Lei Zhang, 2015-12-21 17:09:56]

Description was changed from

==========
Fix JS seconds since epoch to date conversions.

BUG=564736
==========

to

==========
Fix JS seconds since epoch to date conversions.

BUG=515137,564736
==========

[Lei Zhang, 2015-12-21 17:10:14]

thestig@chromium.org changed reviewers:
+ ochang@chromium.org

[Lei Zhang, 2015-12-21 17:14:20]

+ochang

[Tom Sepez, 2015-12-21 17:57:54]

LGTM. Some thoughts:


Can we add a pair of tests for the values N and N+1, chosen so that N maps to
year Y but N+1 maps to year Y+1? Do we have an outside source to validate the
tests against?

[Oliver Chang, 2015-12-21 17:59:12]

lgtm

https://codereview.chromium.org/1533233002/diff/40001/fpdfsdk/src/javascript/...
File fpdfsdk/src/javascript/JS_Value.cpp (right):

https://codereview.chromium.org/1533233002/diff/40001/fpdfsdk/src/javascript/...
fpdfsdk/src/javascript/JS_Value.cpp:672: int y = 1970 + (int)(t / (365.2425 *
86400000));
nit: get rid of the C style cast while we're here?

[Lei Zhang, 2015-12-21 18:46:45]

On 2015/12/21 17:57:54, Tom Sepez (ooo) wrote:
> LGTM. Some thoughts:
> 
> 
> Can we add a pair of tests for the values N and N+1, chosen so that N maps to
> year Y but N+1 maps to year Y+1? Do we have an outside source to validate the
> tests against?

I added another test case for 0 and -0.001. I checked the 1968 date manually.

[Lei Zhang, 2015-12-21 18:46:51]

https://codereview.chromium.org/1533233002/diff/40001/fpdfsdk/src/javascript/...
File fpdfsdk/src/javascript/JS_Value.cpp (right):

https://codereview.chromium.org/1533233002/diff/40001/fpdfsdk/src/javascript/...
fpdfsdk/src/javascript/JS_Value.cpp:672: int y = 1970 + (int)(t / (365.2425 *
86400000));
On 2015/12/21 17:59:12, Oliver Chang wrote:
> nit: get rid of the C style cast while we're here?

Done.

[Lei Zhang, 2015-12-21 18:48:06]

Description was changed from

==========
Fix JS seconds since epoch to date conversions.

BUG=515137,564736
==========

to

==========
Fix JS seconds since epoch to date conversions.

BUG=515137,564736
R=ochang@chromium.org, tsepez@chromium.org

Committed:
https://pdfium.googlesource.com/pdfium/+/b426e3edde040089b70d1a223c83b90957aa...
==========

[Lei Zhang, 2015-12-21 18:48:07]

Committed patchset #4 (id:60001) manually as
b426e3edde040089b70d1a223c83b90957aa571d (presubmit successful).