Incorrect parsing of fractional seconds in ISO-8601 when no timezone is specified

[benj-dobs]

Describe the bug DayJS thinks that the time '00:00:00.5' is five milliseconds after midnight, but it should be 500 milliseconds after midnight.

Reproduction:

const dayjs = require('dayjs');
const dateWithoutSpecifiedTimezone = dayjs('2000-01-01T00:00:00.5');
const dateInUTC = dayjs('2000-01-01T00:00:00.5Z');

dateInUTC.toISOString(); // '2000-01-01T00:00:00.500Z' - Correct
dateWithoutSpecifiedTimezone.toISOString(); // '2000-01-01T00:00:00.005Z' - Incorrect - should be '2000-01-01T00:00:00.500Z'

Expected behavior It should interpret the number of seconds ss.SSS as a decimal fraction, no matter how many decimal places are given, regardless of whether there is a timezone specified

Information

• Day.js Version: 1.11.2
• OS: macOS 12
• Browser: Bug reproduced in Safari and Node.js
• Time zone: BST (UTC+1)

[BePo65]

In this regard dayjs is consistent to what moment does. If we look at the documentation of moment we see:

Note that the number of S characters provided is only relevant when parsing in strict mode. In standard mode, S, SS, SSS, SSSS are all equivalent, and interpreted as fractions of a second. For example, .12 is always 120 milliseconds, passing SS will not cause it to be interpreted as 12 milliseconds.

So IMHO the result of your example is correct, as dayjs tries to be as close to moment as possible (without sacrificing the size).

[benj-dobs]

@BePo65 I think that documentation is describing the behaviour I think is correct, not the behaviour I'm observing.

Moment and Dayjs do not behave the same out-of-the-box in this case:

https://codesandbox.io/s/interesting-hill-6lji80?file=/src/index.js

[BePo65]

Oh, I missed the output from dayjs 😳

I created a pr for this (pr #1936)

[benj-dobs]

Amazing, thank you!