sveltejs / sveltejs/kit

Would love a guide on handling timezones in SvelteKit

Open
#13,696 4 comments 3 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

documentation
Dominant language
JavaScript
Stars
20.8k
Forks
2.3k
Avg merge
1d 16h
Merged PRs (30d)
156

Description

Describe the problem

Dealing with timezones in a Universal SvelteKit app isn't that obvious. The user's timezone is only known clientside so I stumbled my way through a solution that:

a) First visit, the page server-side renders with a default timezone of say Los Angeles
b) Then a cookie gets set with the minutes of offset, in a cookie called 'TZ'
c) Subsequent visits confirm that the TZ there matches the current one (it'll change if you move across the world or if daylight savings time toggles)

This gives you a "flash of incorrect timezone" on the first visit, which is unavoidable, but fixed as soon as the page hydrates.

I think a reference solution for this would involve loaders in +layout.server.js to read the cookie, +layout.js to call new Date(), and some code somewhere to set the cookie if not set yet, and also possibly code to put it in context to make available to all components in the tree.

Bonus points if it's reactive and the minutes of offset update when Daylight Savings Time becomes active or inactive.

Any interest?

Describe the proposed solution

See above.

Alternatives considered

No response

Importance

nice to have

Additional Information

No response

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by reviewing the proposed +layout.server.js and +layout.js entry points, focusing on how the TZ cookie can flow through server rendering and hydration. The guide is done when it documents the first-visit fallback, subsequent timezone handling, and daylight-saving updates without leaving the implementation path ambiguous.

Written by the indexing model from the issue text.

Assessment

Tech stack
javascript
Domain
documentation, web-dev
Issue type
Documentation
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.