Emily Chang (e8f70620) at 17 Mar 08:58

Emily Chang (e83e4552) at 17 Mar 08:29

Three bugs fixed:

Bug 1 — 26 March, 11:00 am SGT → 2011: The year capture group (\d{2,4}) was greedily snatching 11 from 11:00 because the position between 11 and : is a valid word boundary. Fixed by adding (?!:\d) — a negative lookahead that says "don't match these digits if they're immediately followed by a colon and another digit". Applied to both the month-first and day-first date patterns.

Bug 2 — Tuesday, 10 March 2026, 8PM → MARCH timezone error: Two-part failure. parseRelativeTime treats bare weekday names as relative dates (its next|this|last qualifier is optional), so Tuesday set relativeDate = "next Tuesday" and the code was skipping all absolute date parsing entirely. Then "next tuesday" (lowercase) failed to match "Tuesday" in the string, so the date was never removed from timeInput, leaving 10 March exposed — and the time regex grabbed 10 as the hour and March as the timezone. Fixed by: (1) always running absolute date parsing first and only using relativeDate as a fallback when no absolute date is found, and (2) adding bare weekday names to REL_DAY_PATTERNS so Tuesday gets stripped from timeInput regardless.

Bug 3 — no timezone → should assume local: When no timezone abbreviation, GMT offset, or city name is found anywhere in the string, the parser now falls back to Intl.DateTimeFormat().resolvedOptions().timeZone (your browser's local timezone) instead of leaving whatever was previously selected.

Emily Chang (60512be0) at 17 Mar 08:29

... and 1 more commit

Three bugs fixed:

Bug 1 — 26 March, 11:00 am SGT → 2011: The year capture group (\d{2,4}) was greedily snatching 11 from 11:00 because the position between 11 and : is a valid word boundary. Fixed by adding (?!:\d) — a negative lookahead that says "don't match these digits if they're immediately followed by a colon and another digit". Applied to both the month-first and day-first date patterns.

Bug 2 — Tuesday, 10 March 2026, 8PM → MARCH timezone error: Two-part failure. parseRelativeTime treats bare weekday names as relative dates (its next|this|last qualifier is optional), so Tuesday set relativeDate = "next Tuesday" and the code was skipping all absolute date parsing entirely. Then "next tuesday" (lowercase) failed to match "Tuesday" in the string, so the date was never removed from timeInput, leaving 10 March exposed — and the time regex grabbed 10 as the hour and March as the timezone. Fixed by: (1) always running absolute date parsing first and only using relativeDate as a fallback when no absolute date is found, and (2) adding bare weekday names to REL_DAY_PATTERNS so Tuesday gets stripped from timeInput regardless.

Bug 3 — no timezone → should assume local: When no timezone abbreviation, GMT offset, or city name is found anywhere in the string, the parser now falls back to Intl.DateTimeFormat().resolvedOptions().timeZone (your browser's local timezone) instead of leaving whatever was previously selected.

Emily Chang (e83e4552) at 17 Mar 08:28

Hey team, there is a possible regression reported by Customer (Internal ticket). I'm gathering information from Customer, will raise a new issue or update integration_event_filters schema breaks Slack i... (#591948) accordingly.

Hi again, we have another customer on GitLab.com is getting this error again:

/usr/local/bundle/gems/gitlab-4.18.0/lib/gitlab/request.rb:71:in `validate': Server responded with code 400, message: Failed to update integration. {:filter=>["must be a valid json schema"]}. Request URI: https://gitlab.com/api/v4/projects/53851373/services/jira (Gitlab::Error::BadRequest)

They run an automation which runs every hour to ensure projects are all setup correctly. One of the things that it does it configure the Jira Issues integration via the REST API (https://docs.gitlab.com/api/project_integrations/#set-up-jira-issues). There is no filters field anywhere on that page.

Were there any new changes?

The following customer is interested in this capability

• Subscription: GitLab Ultimate
• Product: gitlab.com
• Link to request: https://gitlab.zendesk.com/agent/tickets/700888
• Priority: customer priority5
• Why interested: They want to mirror to a public repo for open source contribution but would need to excluse certain files
• Current solution for this problem: Propose to have another "cleaned" repo to set up for mirroring.
• Impact to the customer of not having this: Setup and configuration needed for an extra repo

Pasting reply from internal Slack thread:

Both versions of duo code review exist and depending on the add on user has, we decide which version of duo code review they would use:

Duo Enterprise: classic version
Duo Pro/Core: DAP flow

Classic version docs: https://docs.gitlab.com/user/gitlab_duo/code_review_classic/

Agentic version docs: https://docs.gitlab.com/user/duo_agent_platform/flows/foundational_flows/code_review/