The booking page holds its slots in IST, because that is where the calls are taken from. Visitors are anywhere. Every slot therefore has to be converted, and the standard move is to install a timezone library and stop thinking about it.
Before installing anything, the question worth asking is what the library would actually be doing. Almost all of the weight in date-fns-tz or Luxon’s zone support is daylight saving: the rules, the history of the rules, and the awkward hours that appear and disappear twice a year.
India does not observe daylight saving. IST is UTC+5:30 in January and UTC+5:30 in July, and has been since 1945. The offset never moves, so the conversion is not a lookup — it is subtraction.
// An IST wall-clock time on a given date, as a true instant.
function instantFor(year: number, month: number, day: number, minutes: number) {
return new Date(Date.UTC(year, month, day, 0, minutes - 330))
}That returns a real point in time. Rendering it in the visitor’s zone is then the browser’s job, and the browser is very good at it — toLocaleTimeString already knows their zone and their own daylight saving. The half of the problem that is genuinely hard is handled by code that ships with every browser.
Where this stops being true
The reasoning is specific, and it is worth writing down precisely because it does not generalise. Move the host to London and this breaks twice a year, silently, by an hour. The trick is not "you do not need a timezone library". It is "this particular zone has no DST, which is why the arithmetic is safe here".
So the constant lives beside a comment saying exactly that, in the content file rather than buried in a component. If the host ever moves, the thing to change is obvious and the reason it must change is written down next to it.
A shortcut is only safe when the condition that makes it safe is written next to it.