parsing difference with time offset between moment and dayjs about dayjs

[iamkun]

fixed thanks

[Imperat]

Fantastic! It has same results. Thank you!

[iamkun]

Thanks, should be a bug. Will check it soon

[tareqlol-zz]

I have checked other related issues mentioning that replacing the dashes and "T" will solve it for now but I guess it should be fixed !73
.replace(/-/g,'/').replace('T', ' ')

Just wanted to reference it in case it helps. Thanks :)

[Imperat]

Hi, @iamkun. I'm going to update regular expression and fix the function parseDate. But I misunderstand why we need to parse the string in ISO 8601 format in this place:

  if ((typeof date === 'string') && (reg = date.match(C.REGEX_PARSE))) {
    // 2018-08-08 or 20180808
    return new Date(
      reg[1], reg[2] - 1, reg[3] || 1,
      reg[5] || 0, reg[6] || 0, reg[7] || 0, reg[8] || 0
    )
  }

instead to pass this string into constructor directly:

if (typeof date === 'string') {
  return new Date(date);
}

Can you clarify it, please?

[iamkun]

The regex is used to parse date string like 2018-01-01, 2018-01 that is not in ISO format.

But in the case, this date string passed our regex, which is incorrect.

[Imperat]

Thank you, @iamkun. Just another question.
The last matching group from regular expression:
.?(\d{1,3})
It means amount of milliseconds?
We pass it as last argument to new Date() constructor.
I'm afraid that we have the bug in this place also.

[Imperat]

For example:
12:20:12.1 means 1/10 part of second - 100 milliseconds.
12:20:12.10 means 10/100 (1/10 also )
12:20:12.123 means 123 milliseconds
But I see that we take this value from string and pass it as milliseconds.
Please, let me know if I'm wrong.

[iamkun]

No, according to JS Date object, 12:20:12.1 means 12:20:12:001

[Imperat]

It's strange, because of 2018-01-02T12:20:12.1 is correct ISO 8601 string with 100 milliseconds.
Quote from Wikipedia:
Decimal fractions may be added to any of the three time elements. However, a fraction may only be added to the lowest order time element in the representation. A decimal mark, either a comma or a dot (without any preference as stated in resolution 10 of the 22nd General Conference CGPM in 2003,[24] but with a preference for a comma according to ISO 8601:2004)[25] is used as a separator between the time element and its fraction. To denote "14 hours, 30 and one half minutes", do not include a seconds figure. Represent it as "14:30,5", "1430,5", "14:30.5", or "1430.5". There is no limit on the number of decimal places for the decimal fraction. However, the number of decimal places needs to be agreed to by the communicating parties. For example, in Microsoft SQL Server, the precision of a decimal fraction is 3, i.e., "yyyy-mm-ddThh:mm:ss[.mmm]".[26]

If we write in our doc that we support standard ISO 8601, do we need to fix this behavior or not?

[iamkun]

That's different. We are correct. You could try it yourself before submitting comments.

[Imperat]

I try next code:

console.log(dayjs('2018-05-14T08:50:23.1').valueOf())
console.log(dayjs('2018-05-14T08:50:23.100').valueOf())

and it has different output:

1526273423001
1526273423100

Sorry for confusing, I just misunderstand why in Wikipedia it's written that it can be interpreted as decimal fraction (according ISO 8601), but we mean that this is just milliseconds :(

[iamkun]

try '2018-05-14T08:50:23.1Z' then, THIS IS ISO 8601 format.

[zctya]

抓紧时间修复啊 @iamkun ^_^