Introduction

Hey, I'm working on a project which relies on a consistent order of the elements in the array returned by the getDayNamesMin function, no matter which time zone the runtime is set to. To be specific, my code relies on the returned array always having Sunday at index 0, Monday at 1 etc. To double check, I had a look on the actual implementation. Manual testing revealed changing the runtime's time zone does not affect the order of the elements in the returned array as long as the so called "Server rendered" array is set and the function does not "Fallback to Intl".

The problem

[
  new Date('1970-01-04T00:00:00.000Z').toLocaleDateString(locale, { weekday: 'narrow' }),
  new Date('1970-01-05T00:00:00.000Z').toLocaleDateString(locale, { weekday: 'narrow' }),
  new Date('1970-01-06T00:00:00.000Z').toLocaleDateString(locale, { weekday: 'narrow' }),
  new Date('1970-01-07T00:00:00.000Z').toLocaleDateString(locale, { weekday: 'narrow' }),
  new Date('1970-01-08T00:00:00.000Z').toLocaleDateString(locale, { weekday: 'narrow' }),
  new Date('1970-01-09T00:00:00.000Z').toLocaleDateString(locale, { weekday: 'narrow' }),
  new Date('1970-01-10T00:00:00.000Z').toLocaleDateString(locale, { weekday: 'narrow' }),
];

The above array will have Sunday at index 0, matching the "Server rendered" array globalThis.dayNamesMin, but only if the runtime's time zone is UTC or any time zone with a positive offset, e.g. +01:00. This is because the Date.prototype.toLocaleDateString method formats the returned string according to the runtime's local time zone. January 4, 1970 is a Sunday but invoking the Date constructor with an ISO string – including the "Z" suffix for UTC – like "1970-01-04T00:00:00.000Z" in a runtime with a negative time zone offset will result in the local date being January 3, 1970 which is a Saturday.

If you want to check for yourself, just switch the time zone of your local machine to e.g. America/New_York and run npm run test. You'll see multiple tests fail.

The solution

Instead of using the ISO string as the constructor argument, pass separate Number arguments for the year, month and day. This way, the arguments are treated as being in local time, which in turn results in Sunday always being the first element in the array, no matter the runtime's time zone.

Affected code

The issue affects all of the following functions

• getDayNames
• getDayNamesShort
• getDayNamesMin
• getMonthNames
• getMonthNamesShort

Tests

I duplicated the tests covering the affected functions and adjusted those tests to use two different time zones: one with a negative and one with a positive offset from UTC.

Implications

One could consider this a breaking change, due to the order of the returned arrays being different compared to the current state, but then again those functions never promised any specific order. Still, based on assumptions that developers might make, I myself would consider this breaking.

On a side note, I dont' even know if there's actually a scenario where the "Server rendered" arrays inside globalThis wouldn't be present.

Contributing guidelines

I know I didn't follow the guidelines regarding the "Signed-off-by" suffix to my commit message as I'm not willing to disclose my legal name, so feel free to close this PR and copy my changes to a new unrelated PR. My goal is to just get this fixed.