[Webkit-unassigned] [Bug 91469] New: [Forms] Test expectations of datetime/datetime-local/time should not contain milliseconds when they aren't expected

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=91469

           Summary: [Forms] Test expectations of
                    datetime/datetime-local/time should not contain
                    milliseconds when they aren't expected
           Product: WebKit
           Version: 528+ (Nightly build)
          Platform: Unspecified
        OS/Version: Unspecified
            Status: NEW
          Severity: Normal
          Priority: P2
         Component: Tools / Tests
        AssignedTo: webkit-unassigned at lists.webkit.org
        ReportedBy: yosin at chromium.org


Following tests have wrong test expectations:
 * fsat/from/datetime/datetime-stepup-stepdown-from-renderer.html
 * fsat/from/datetimelocal/datetimelocal-stepup-stepdown-from-renderer.html
 * fsat/from/time/time-stepup-stepdown-from-renderer.html

For very big step value like:
  shouldBe('stepUp("2012-02-12T20:13Z", "3.40282346e+38", null)', '"276760-09-13T00:00:00.000Z"');

In this case, an expectation should not have milliseconds, e.g. "276760-09-13T00:00:00".

Before r119948 (introducing Decimal arithmetic), BasseDateAndTimeInputType::serialize checked
whether resulted string containing milliseconds or not by using fmod(step, msecPerSecond), where
msecPerSecond is 1000.

This expression works fine when step isn't big number, and fmod(3.40282346e+38, 1000) returns 616
on my x86 linux box.

Since r119948, BaseDateAndTimeInput::serialize uses same expression but it is done by decimal arithmetic,
e.g. step.remainder(msecPerSecond).isZero(), and this expression returns false for big number.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.