Doug Parker 13f050d220 test: construct local Date objects to fix timezone flakiness ... Replaced testing constructions of `Date` objects from `formatDate` tests from plain ISO strings over to 'new Date(year, month, date)'. Instantiating 'new Date("2024-01-01")' parses the string strictly as UTC midnight ("2024-01-01T00:00:00.000Z"). When local operations execute (such as calculating `getThursdayThisIsoWeek` boundaries), the UTC date shifts relative to the executing machine's timezone. For example, in PST (GMT-8), that date translates exactly to 'December 31st 16:00:00', pushing week boundaries backwards. By wrapping date constructs explicitly as 'new Date(2024, 0, 1)', it natively guarantees local midnight execution and prevents boundaries shifting on global CI Remote Build Execution (RBE) workers. Example (from a machine in PST): ```javascript > new Date('2024-01-01') Sun Dec 31 2023 16:00:00 GMT-0800 (Pacific Standard Time) > new Date(2024, 0, 1) Mon Jan 01 2024 00:00:00 GMT-0800 (Pacific Standard Time) ``` (cherry picked from commit 61ee183fa7)		2026-03-26 18:34:13 +01:00
..
format_date_spec.ts	test: construct local Date objects to fix timezone flakiness	2026-03-26 18:34:13 +01:00
format_number_spec.ts	refactor(common): convert scripts within packages/common to relative imports (#60623)	2025-04-01 15:58:51 +00:00
locale_data_api_spec.ts	refactor(common): convert scripts within packages/common to relative imports (#60623)	2025-04-01 15:58:51 +00:00
localization_spec.ts	refactor(common): convert scripts within packages/common to relative imports (#60623)	2025-04-01 15:58:51 +00:00