UTC Plugin Milliseconds parsing

[ilueckel]

Describe the bug
When I use the UTC-Plugin and try to parse a string with milliseconds, it changes the time (I'm CET). If I append a "Z" to my string, this does not happen (see example)

Expected behavior
Parsing a string without milliseconds creates a correct representation of the date (with or without "Z" at the end). Adding milliseconds to the script should not change this behavior.

Example

dayjs.utc('2019-03-25T06:41:00');
/** { [Number: 1553496060000]
      '$L': 'en',
      '$u': true,
      '$d': 2019-03-25T06:41:00.000Z,
      '$y': 2019,
      '$M': 2,
      '$D': 25,
      '$W': 1,
      '$H': 6,
      '$m': 41,
      '$s': 0,
      '$ms': 0 }
*/

dayjs.utc('2019-03-25T06:41:00Z');
/** { [Number: 1553496060000]
      '$L': 'en',
      '$u': true,
      '$d': 2019-03-25T06:41:00.000Z,
      '$y': 2019,
      '$M': 2,
      '$D': 25,
      '$W': 1,
      '$H': 6,
      '$m': 41,
      '$s': 0,
      '$ms': 0 }
*/
// They are the same

dayjs.utc('2019-03-25T06:41:00.654321');
// This one is one hour of (the first example isn't)
/** { [Number: 1553492460654]
      '$L': 'en',
      '$u': true,
      '$d': 2019-03-25T05:41:00.654Z,
      '$y': 2019,
      '$M': 2,
      '$D': 25,
      '$W': 1,
      '$H': 5,
      '$m': 41,
      '$s': 0,
      '$ms': 654 }
*/

dayjs.utc('2019-03-25T06:41:00.654321Z')
// This one isn't one hour off (as I would expect it for the previous one too)
/** { [Number: 1553496060654]
      '$L': 'en',
      '$u': true,
      '$d': 2019-03-25T06:41:00.654Z,
      '$y': 2019,
      '$M': 2,
      '$D': 25,
      '$W': 1,
      '$H': 6,
      '$m': 41,
      '$s': 0,
      '$ms': 654 }
*/

Information

• Day.js Version: v1.8.11
• OS: Windows 10
• Browser: Chrome, Jest

[iamkun]

@ilueckel
I think we currently support 2019-03-25T06:41:00.654 (3 digits ms), you could try this first to see if it works as expected.

Plus, just wondering what's this date format that contains 6 digits millisecond?

[ilueckel]

Restricting it to three digits would fix it. I'll guess I do this instead.

The date strings are generated in a Spring Boot Web App from LocalDateTime Objects with Jackson Json. I will change the default format there.

[ilueckel]

I tried to use

dayjs.utc('2019-03-25T06:41:00.654321', 'YYYY-MM-DDTHH:mm:ss.SSSSSS')

but result was still

  { [Number: 1553492460654]
      '$L': 'en',
      '$u': true,
      '$d': 2019-03-25T05:41:00.654Z,
      '$y': 2019,
      '$M': 2,
      '$D': 25,
      '$W': 1,
      '$H': 5,
      '$m': 41,
      '$s': 0,
      '$ms': 654 }

[iamkun]

Yes, currently we only support parsing 3 digits millisecond both parse and customParseForamt plugin

[igaloly]

@iamkun
Why there's a difference between 3 / 6 digits?

[stefanv]

What is the motivation for not supporting more digits?

[iamkun]

Of course, we could support it if needed.

[cyberfly]

I am scratching my head and the work around actually fix this

https://stackoverflow.com/questions/61368563/day-js-is-not-converting-utc-to-local-time

[iamkun]

sorry for the inconvenience, and it is fixed in #1010

[iamkun]

🎉 This issue has been resolved in version 1.8.34 🎉

The release is available on:

• npm package (@latest dist-tag)
• GitHub release

Your semantic-release bot 📦🚀

[josefsmrz]

Hi, there seems to be another problem that manifests very similarly and might be connected.

Conversion from UTC to local time doesn't work when parsing it as 'DD/MM/YYYY H:mm'.

//returns '06/09/2019 9:09' - correct CEST
dayjs.utc('2019/09/06 7:09', 'YYYY/MM/DD H:mm').local().format('DD/MM/YYYY H:mm')
 
//returns '06/09/2019 7:09' - incorrect
dayjs.utc('06/09/2019 7:09', 'DD/MM/YYYY H:mm').local().format('DD/MM/YYYY H:mm')

//returns 'invalid date'
dayjs.utc('31/12/2019 7:09', 'DD/MM/YYYY H:mm').local().format('DD/MM/YYYY H:mm')