iamkun / iamkun/dayjs

Isoweek bug when customParseFormat is active

Open
#2,632 2 comments 2 reactions 0 assignees View on GitHub
Dominant language
JavaScript
Stars
48.7k
Forks
2.5k
PR merge metrics
No merged PRs in 30d

Description

**Describe the bug**
When I try to get the iso week number from a date, the isoWeek function is not correct.

**Information**
Bug has been reproduced in this [sandbox](https://codesandbox.io/p/sandbox/dayjs-isoweek-and-customparseformat-bug-t4xg37)

We get a very incoherent value :
- `dayjs.utc("2024-01-16T22:00:00.000Z").locale("fr").tz("Europe/Paris").isoWeek()` return 3
- `dayjs.utc("2024-01-16T23:00:00.000Z").locale("fr").tz("Europe/Paris").isoWeek()` return 2

That makes no sense, if A > B then A.isoWeek() >= B.isoWeek()

I don't really understand what is happening.

My guess is that when time is 23-23h59, the timezone makes the day change from 16 to 17 according to TZ. This day change leads to a decremented isoWeek.

I have tried to remove `customParseFormat` from used plugin and it started working. You can try it on the sandbox. However I need this plugin to make parse date in my TZ.

Thanks for your help.

Contributor guide

Open the contributing guide

Research direction

Start by running the linked CodeSandbox with customParseFormat, utc, timezone, and isoWeek enabled, then compare the two timestamps and plugin interactions. Trace how the plugins parse and convert the date before isoWeek() calculates the result. Done means the reported timestamps produce consistent ISO week values and a regression test covers the case.

Written by the indexing model from the issue text.

Assessment

Tech stack
javascript
Domain
api
Issue type
Bug
Difficulty
3/5
Estimated time
1-2 days
Activity status
Active
Clarity
Mostly clear
Newbie friendliness
62/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.