customParseFormat parses an incomplete datetime

[spudcud]

Describe the bug
Using the format "MM/DD/YYYY HH:mm" customParseFormat incorrect accepts the string "10/18/2019 08:5_" as 10/18/2019 08:05. Without customParseFormat dayjs correctly tags that as Invalid Date until the minutes are typed in. dayjs("10/18/2019 08:5_", "MM/DD/YYYY HH:mm");

I would simply not use customParseFormat except it is used in a third party library so I cannot remove it.

https://codesandbox.io/s/dayjs-customparseformat-early-parse-upui5

Expected behavior
Invalid Date

Information

• Day.js Version 1.8.16
• OS: Windows
• Browser chrome 77
• Time zone: GMT-04:00 EST

[spudcud]

I modified the third party code to not use customParseFormat and it correctly parses but the issue is that dayjs.utc("10/18/2019 08:00", "MM/DD/YYYY HH:mm"); does not treat the value as utc but treats it as local. With customParseFormat it treats the passed in value as utc which is what it should do. The below sample shows how if you use customParseFormat it correctly does it and if you remove it then it doesn't work.

https://codesandbox.io/s/dayjs-parse-utc-sw0w9

[iamkun]

https://runkit.com/embed/d6xjrs5demn3

Hi, dayjs.utc() returns a UTC time in this test link

[spudcud]

It should be 0800 UTC as that is what is passed in. If you include customParseFormat it will be 0800 UTC. They function very differently. If you run my codesandbox you can uncomment or comment out customParseFormat and see how it is working in the 2 scenarios. I need a way to tell dayjs that the string passed in is UTC

[iamkun]

@spudcud

// 10/18/2019 08:00 as utc time 
dayjs.utc("10/18/2019 08:00", "MM/DD/YYYY HH:mm").toISOString() // 2019-10-18T08:00:00.000Z

// // 10/18/2019 08:00 as local time (GMT+8 timing)
dayjs("10/18/2019 08:00", "MM/DD/YYYY HH:mm").toISOString() // 2019-10-18T00:00:00.000Z

[spudcud]

@iamkun I cannot see what plugins you do and don't have when you are just outputting the results. Below is what I am using and what I am seeing. They do not match when using customParseFormat and when not.

This output for utc is incorrect because customParseFormat is not used. This one is wrong.
`
import dayjs from "dayjs";
import utc from "dayjs/plugin/utc";
dayjs.extend(utc);

dayjs.utc("10/18/2019 08:00", "MM/DD/YYYY HH:mm").toISOString(); // 2019-10-18T12:00:00.000Z -- Wrong. should be 0800Z
dayjs("10/18/2019 08:00", "MM/DD/YYYY HH:mm").toISOString(); // 2019-10-18T12:00:00.000Z
`

Here using customParseFormat it treats the string as utc which is what it should do.
`
import dayjs from "dayjs";
import customParseFormat from "dayjs/plugin/customParseFormat";
import utc from "dayjs/plugin/utc";
dayjs.extend(customParseFormat);

dayjs.extend(utc);

dayjs.utc("10/18/2019 08:00", "MM/DD/YYYY HH:mm").toISOString(); //2019-10-18T08:00:00.000Z
dayjs("10/18/2019 08:00", "MM/DD/YYYY HH:mm").toISOString(); // 2019-10-18T12:00:00.000Z
`

We are just missing something in our communication so hopefully we can get on the same page.

[iamkun]

the second argument "MM/DD/YYYY HH: mm" is available only while using 'customParseFormat' plugin, otherwise, it will be ignored. And 10/18/2019 08:00 is not a standard date-time format, so please always parse it with 'customParseFormat' plugin.

[spudcud]

Okay, that still leaves my first post here which is what I was originally writing about

Describe the bug
Using the format "MM/DD/YYYY HH:mm" customParseFormat incorrect accepts the string "10/18/2019 08:5_" as 10/18/2019 08:05. Without customParseFormat dayjs correctly tags that as Invalid Date until the minutes are typed in. dayjs("10/18/2019 08:5_", "MM/DD/YYYY HH:mm");

I would simply not use customParseFormat except it is used in a third party library so I cannot remove it.

https://codesandbox.io/s/dayjs-customparseformat-early-parse-upui5

Expected behavior
Invalid Date

[iamkun]

Still can't see the different

https://runkit.com/embed/23fsmiaraif8

[spudcud]

If moment does the same thing then I believe that is a bug in moment too. How can a user type in a date time if they can't finish filling in the final value before it accepts it? How is that a valid datetime and why would it be set to 08:05? That is what I am getting at.

[iamkun]

I'll close this issue since it's been a while since it's been opened. Feel free to reopen if you have updates on this