[plugin] `CustomParseFormat` parsing problem.

[long-woo]

Describe the bug Using the CustomiParseFormat plugin:

Expected behavior Normal, not Invalid Date.

Information

• Day.js Version 1.11.8
• OS: Mac
• Browser Edge
• Time zone: [e.g. GMT-07:00 DST (Pacific Daylight Time)]

[maciejp]

I'm not a maintainer, just wondering why you think the expected behavior of parsing a string that doesn't include the (expected) time component should be creating a valid date? What default value should be assigned to the time component? Should it be set to the current time or to 00:00Z or 00:00 in the timezone it was executed in?

My personal opinion is that marking it as invalid is a better approach than assigning a default value. The latter can easily lead to (hard to track down) bugs.

Curious to hear your opinion!

[MoonlightCapital]

As per docs:

If you don't know the exact format of an input string, but know it could be one of many, you can use an array of formats.

dayjs("12-25-2001", ["YYYY", "YYYY-MM-DD"], 'es', true);

[maciejp]

@MoonlightCapital did you mean that if @long-woo wants to parse strings that may or may not contain the time element then dayjs(dateOrDateTimeString, ['DD-MM-YYYY', 'DD-MM-YYYY HH:mm:ss']) would be the way?

Yes, this seems like a good idea!

            console.log(dayjs('27-06-2023', 'DD-MM-YYYY HH:mm:ss', 'en', false).isValid()) // false
            console.log(dayjs('27-06-2023', ['DD-MM-YYYY', 'DD-MM-YYYY HH:mm:ss']).isValid()) // true
            console.log(dayjs('27-06-2023', ['DD-MM-YYYY', 'DD-MM-YYYY HH:mm:ss']).toISOString()) // 2023-06-27T00:00:00.000Z

as you can see, when time is not specified it assumes the start of the day.

As a side note - the locale and strict parameters aren't necessary. Strict is great for checking if the date is "semantically correct":

            console.log(dayjs('27-06-2023', 'DD-MM-YYYY', 'en', true).isValid()) // true
            console.log(dayjs('27-26-2023', 'DD-MM-YYYY', 'en', true).isValid()) // false,  26th month doesn't exist