Repository navigation
fix(parser): correct WhatsApp TXT date order when the preferred month is invalid - #506
Merged
Merged
Conversation
… is invalid TXT exports encode dates as month/day/year or day/month/year depending on the device locale, and the parser infers the order from the digits alone. When the preferred order produced a month outside 1-12 the value was still passed to Date(), which rolls it into another month or year instead of failing. That turned ordinary export lines into wrong timestamps: 12/25/2024 -> 2026-01-12 (should be 2024-12-25) 13/01/24 -> 2025-01-01 (should be 2024-01-13) 25/12/24 -> 2026-01-12 (should be 2024-12-25) A component above 12 cannot be a month, so switch to the other order only when the preferred reading is impossible. Dates that already resolved correctly keep their existing interpretation, including the ambiguous month-first cases (01/02/24) and year-first exports (2024/01/02).
Omair-Asdaq
marked this pull request as ready for review
November 3, 2026 17:27
There was a problem hiding this comment.
Copilot was unable to review this pull request because the user who requested the review has insufficient remaining quota. Try requesting a review at a lower effort level.
An organization owner can choose the repository organization as the billing source for reviews requested by members with a paid Copilot license. Learn about Copilot code review billing.
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
The WhatsApp browser-safe text parser misreads dates whose day is above 12 when the export is month-first, and dates whose day is above 12 when the file is day-first with a short year. For example:
12/25/2024was read as day 12, month 25 - an invalid month13/01/24was read as month 13, day 01 - an invalid monthBoth are valid WhatsApp timestamps and come out of the parser as
Invalid Date.Change
buildTimestampnow treats the second part as a month only when it can actually be one. In the long-year branch a second part above 12 switches to month-first; in the short-year branch a first part above 12 switches to day-first. Anything ambiguous (both parts 12 or below) keeps the order the file's locale already implied, so the existing behaviour is unchanged for those.Tests
New case in
packages/parser/src/browser/whatsapp.test.tscovering12/25/2024,13/01/24,25/12/24,02/01/2024,01/02/24and a year-first date.1 failed- the new case, with the timestamps coming back as invalid4 passed69 passedKnown limitations
Ambiguous dates where both leading parts are 12 or below still follow the locale's preferred order; this change only corrects the case where the preferred order is impossible.