getLocalTimeZone cache

[stuartkeith]

I noticed getLocalTimeZone internally caches the result, so it's only calculated once:

react-spectrum/packages/@internationalized/date/src/queries.ts

Lines 118 to 128 in 987f174

	let localTimeZone: string | null = null;
	/** Returns the time zone identifier for the current user. */
	export function getLocalTimeZone(): string {
	// TODO: invalidate this somehow?
	if (localTimeZone == null) {
	localTimeZone = new Intl.DateTimeFormat().resolvedOptions().timeZone;
	}
	return localTimeZone!;
	}

This was added in #2264, with a TODO about invalidating it somehow in the future (which has not been done, as far as I can see).

This can cause unexpected behaviour if the user happens to change timezone (e.g. they close their laptop in one timezone, go somewhere, open it in another timezone).

Does anyone have any insight as to why this was done, or whether it's a known issue? I can see #2264 mentions improving date formatting performance, so I can imagine caching is part of that, although I wonder how much the timezone calculation was contributing to the formatting as opposed to everything else.

[reidbarber]

Looks like there is a proposal for a timezonechange event: whatwg/html#3047

Not sure of a good solution for now, but maybe doing something with the Page Visibility API at the application level. I think that's too opinionated to be included by default though.

[snowystinger]

We could implement polling for this. I assume that's what Google Calendar app does since it appears to notice when I am in a new timezone. That, or they have some API to have it work in Chrome. I haven't ever tried it in Safari or FF.

[stuartkeith]

Thanks for responding. I realised I linked to the wrong PR above so fixed that up.

I agree that maybe it's too opinionated to handle this in the library via polling or similar, although I wonder if it was too opinionated to cache the time zone internally in the first place. If the user is expecting to calculate dates so frequently that the performance is an issue, they could implement their own caching however it suits them (and be responsible for clearing it).

[jasonvarga]

Sorry to comment on an old issue.

I'm running into a similar issue where I'm trying to test something that relies on the user's local timezone.

test.each([
    ['UTC', '...'],
    ['America/New_York', '...'],
])('it gets localized to users timezone (%s)', async (tz, expectedDate) => {
    process.env.TZ = tz;
    expect(...).toBe(...);
});

Using process.env.TZ would normally work but since the value is cached, it doesn't.

Would a setLocalTimeZone(timeZone) method be an acceptable request? Or a resetLocalTimeZone() method?

The latter would allow user-defined logic to refresh the timezone based on polling etc in the other comment.

[snowystinger]

I think that could be acceptable. Would you like to open a PR for further discussion?

[jasonvarga]

Yes I'd be happy to. Just wanted to ask if it was ok before spending time on it. 👍 Thanks!