You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
from REGEX_PARSE = /^(\d{4})[-/]?(\d{1,2})?[-/]?(\d{0,2})[^0-9]*(\d{1,2})?:?(\d{1,2})?:?(\d{1,2})?[.:]?(\d+)?$/
when new Date('2020.05.23') is parsed in chrome2020-05-23T00:00:00.000, and Invalid in safari.
but dayjs('2020.05.23') is parsing as 2020-01-01T05:00:00.023
Expected behavior
dayjs('2020.05.23') should fallback to native Date
Information
I think the problem is that [^0-9]* accepts any characters including .
what commonly used cases are [Tt\s]*, and it seems okay to me.
The text was updated successfully, but these errors were encountered:
I have found that dots are not a valid rule from ISO8601 or things, but it just worked in Chrome only.
So It means, It should not matched in REGEX, and fallback to Date
Describe the bug
from
REGEX_PARSE = /^(\d{4})[-/]?(\d{1,2})?[-/]?(\d{0,2})[^0-9]*(\d{1,2})?:?(\d{1,2})?:?(\d{1,2})?[.:]?(\d+)?$/
when
new Date('2020.05.23')
is parsed in chrome2020-05-23T00:00:00.000
, and Invalid in safari.but
dayjs('2020.05.23')
is parsing as2020-01-01T05:00:00.023
Expected behavior
dayjs('2020.05.23')
should fallback to native DateInformation
I think the problem is that
[^0-9]*
accepts any characters including.
what commonly used cases are
[Tt\s]*
, and it seems okay to me.The text was updated successfully, but these errors were encountered: