Allow customization of lastUpdated timezone

[odnamrataizem]

What version of starlight are you using?

0.32.1

What version of astro are you using?

5.3.0

What package manager are you using?

pnpm

What operating system are you using?

macOS

What browser are you using?

Chrome

Describe the Bug

When using lastUpdated: true and not manually setting lastUpdated on a post's frontmatter (or actually setting it to a full ISO8601 date with timezone, e.g.: 2025-02-23T22:29:29.000-03:00), sometimes it will yield an incorrect date. My timezone is UTC-3 (or, better yet, America/Sao_Paulo), but LastUpdate.astro always creates a date in UTC, meaning if I update a post between 9:00 PM and 11:59 PM on my timezone, it'll display the date as if the update were made on the next day. This is a consequence of a (correct) fix made in #1170.

While the datetime attribute is correct in the following Chrome DevTools screenshot, the text contents are not (in this instance, the post was updated on 02/23/2025 10:29:29 PM, UTC-3):

As such, I propose that LastUpdate.astro should accept a custom timezone.

Link to Minimal Reproducible Example

https://idx.google.com/astro-starlight-5886471

Participation

• I am willing to submit a pull request for this issue.

[delucis]

Thank you for the suggestion @odnamrataizem! I’ve converted this to a feature request as I don’t think this is strictly speaking a bug: technically, no matter which time zone is chosen, the result could appear to be “wrong” to someone.

Currently, the best workaround is to use a component override to provide your own logic for converting the date, for example:

---
// LastUpdated.astro
const { lang, lastUpdated } = Astro.locals.starlightRoute;
---

{
	lastUpdated && (
		<p>
			{Astro.locals.t('page.lastUpdated')}{' '}
			<time datetime={lastUpdated.toISOString()}>
				{lastUpdated.toLocaleDateString(lang, { dateStyle: 'medium', timeZone: 'America/Sao_Paulo' })}
			</time>
		</p>
	)
}