search

iamkun / dayjs

⏰ Day.js 2kB immutable date-time library alternative to Moment.js with the same modern API
https://day.js.org
MIT License
46.67k stars 2.28k forks source link

Parsing meridiem characters in strings doesn't work. #1373

Open zdfs opened 3 years ago

zdfs commented 3 years ago

Describe the bug I have a runkit example here: https://runkit.com/zdfs/dayjs-parse-meridiem

When parsing strings with meridiem characters, even in strict mode, meridiem characters don't affect what hour the dayjs object creates.

Expected behavior Meridiem for KO from locale meridiem: (hour) => (hour < 12 ? '오전' : '오후')

In my runkit example, const test = dayjs('2019/9/2 오후 3:30:00', 'YYYY/M/D A h:mm:ss', "ko", true); should create a time object in the afternoon, not in the morning.

Information

Mike-Diaz commented 3 years ago

I can also reproduce using the Chinese zh-cn locale. console.log(dayjs('2021/03/11 12:23:45 中午', 'YYYY/MM/DD hh:mm:ss A', 'zh-cn', true)); returns: 

 d {
      '$L': 'zh-cn',
      '$u': undefined,
      '$d': Invalid Date,
      '$y': 2021,
      '$M': 2,
      '$D': 11,
      '$W': 4,
      '$H': 0,
      '$m': 23,
      '$s': 45,
      '$ms': 0
    }

Hour has been set to 0.

eriklharper commented 1 year ago

I feel like I'm having this same issue with every one of my h12 hour cycle locales I'm testing dayjs with here: https://codepen.io/eriklharper/pen/LYJvvLQ?editors=0010 The only difference between the reported issue's setup and mine is that I'm just using the LTS option instead of sending in a custom parse format. You'll notice in the table of locales I have in that example, the only 12-hour locale that parses the time correctly is en-US. Even en-AU and en-CA (which use pm and p.m. respectively as opposed to PM) doesn't work when the time value is set to the afternoon. All of the values in the rightmost column should resolve to the same UTC time in the afternoon, which in this case is 17:11:22 GMT:

image