diff --git a/src/constant.js b/src/constant.js
--- a/src/constant.js
+++ b/src/constant.js
@@ -26,5 +26,5 @@ export const FORMAT_DEFAULT = 'YYYY-MM-DDTHH:mm:ssZ'
 export const INVALID_DATE_STRING = 'Invalid Date'
 
 // regex
-export const REGEX_PARSE = /^(\d{4})[-/]?(\d{1,2})?[-/]?(\d{0,2})[^0-9]*(\d{1,2})?:?(\d{1,2})?:?(\d{1,2})?.?(\d{1,3})?$/
+export const REGEX_PARSE = /^(\d{4})[-/]?(\d{1,2})?[-/]?(\d{0,2})[^0-9]*(\d{1,2})?:?(\d{1,2})?:?(\d{1,2})?.?(\d+)?$/
 export const REGEX_FORMAT = /\[([^\]]+)]|Y{2,4}|M{1,4}|D{1,2}|d{1,4}|H{1,2}|h{1,2}|a|A|m{1,2}|s{1,2}|Z{1,2}|SSS/g
diff --git a/src/index.js b/src/index.js
--- a/src/index.js
+++ b/src/index.js
@@ -60,12 +60,13 @@ const parseDate = (cfg) => {
     const d = date.match(C.REGEX_PARSE)
     if (d) {
       const m = d[2] - 1 || 0
+      const ms = (d[7] || '0').substring(0, 3)
       if (utc) {
         return new Date(Date.UTC(d[1], m, d[3]
-          || 1, d[4] || 0, d[5] || 0, d[6] || 0, d[7] || 0))
+          || 1, d[4] || 0, d[5] || 0, d[6] || 0, ms))
       }
       return new Date(d[1], m, d[3]
-          || 1, d[4] || 0, d[5] || 0, d[6] || 0, d[7] || 0)
+          || 1, d[4] || 0, d[5] || 0, d[6] || 0, ms)
     }
   }
 

diff --git a/test/parse.test.js b/test/parse.test.js
--- a/test/parse.test.js
+++ b/test/parse.test.js
@@ -81,6 +81,14 @@ describe('Parse', () => {
     expect(normalized.toISOString()).toEqual(expected)
   })
 
+  it('parses unlimited millisecond', () => {
+    const date = '2019-03-25T06:41:00.999999999'
+    const ds = dayjs(date)
+    const ms = moment(date)
+    expect(ds.valueOf()).toEqual(ms.valueOf())
+    expect(ds.millisecond()).toEqual(ms.millisecond())
+  })
+
   it('String Other, Null and isValid', () => {
     global.console.warn = jest.genMockFunction()// moment.js otherString will throw warn
     expect(dayjs('otherString').toString().toLowerCase()).toBe(moment('otherString').toString().toLowerCase())
@@ -134,4 +142,10 @@ describe('REGEX_PARSE', () => {
     expect(dayjs(date).valueOf()).toBe(moment(date).valueOf())
     expect(d.join('-')).toBe('2020/9/30-2020-9-30----')
   })
+  it('2019-03-25T06:41:00.999999999', () => {
+    const date = '2019-03-25T06:41:00.999999999'
+    const d = date.match(REGEX_PARSE)
+    expect(dayjs(date).valueOf()).toBe(moment(date).valueOf())
+    expect(d.join('-')).toBe('2019-03-25T06:41:00.999999999-2019-03-25-06-41-00-999999999')
+  })
 })
diff --git a/test/plugin/utc.test.js b/test/plugin/utc.test.js
--- a/test/plugin/utc.test.js
+++ b/test/plugin/utc.test.js
@@ -94,6 +94,14 @@ describe('Parse UTC ', () => {
     expect(dayjs.utc(d).format()).toEqual('2018-09-06T19:34:28Z')
     expect(dayjs.utc(d).format()).toEqual(moment.utc(d).format())
   })
+
+  it('parses unlimited millisecond in utc', () => {
+    const date = '2019-03-25T06:41:00.999999999'
+    const ds = dayjs.utc(date)
+    const ms = moment.utc(date)
+    expect(ds.valueOf()).toEqual(ms.valueOf())
+    expect(ds.millisecond()).toEqual(ms.millisecond())
+  })
 })
 
 it('Clone retains the UTC mode', () => {

UTC Plugin Milliseconds parsing
**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


@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?
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.
I think it's also OK to update this line
https://github.com/iamkun/dayjs/blob/dev/src/constant.js#L29
the last `3` to `6` to solve this issue without any side effect.

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 }
```
Yes, currently we only support parsing 3 digits millisecond both `parse` and `customParseForamt` plugin
@iamkun
Why there's a difference between 3 / 6 digits?
What is the motivation for not supporting more digits?
Of course, we could support it if needed.
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
test/timezone.test.js(1) test/timezone.test.js(2) test/timezone.test.js(3) test/timezone.test.js(4) test/plugin/utc.test.js
test/parse.test.js