I won’t prioritize the DateTime porting immediately then, but I’ll keep it high in the backlog since others will likely hit this pattern too.

Web API wrappers are planned, but locale and time handling need a special isomorphic-aware approach. For your use case, you’d probably want to server-render with a default timezone first, then update client-side - otherwise you’d have to render all dates only after client load.

Some DateTime timezone functions are impractical to transpile directly because they require timezone database libraries like tzdata (Elixir’s default UTCOnlyTimeZoneDatabase only supports UTC). These libraries contain large IANA timezone databases that would bloat the JS bundle. Instead, it’s better to port them manually using Web APIs underneath while maintaining the same Elixir API.

You could theoretically get the timezone like this now:

timezone = ~JS"return Type.string(Intl.DateTimeFormat().resolvedOptions().timeZone)"

This would return something like "Europe/Warsaw", but the DateTime functions to format dates with that timezone won’t compile correctly yet for the reasons mentioned above.

Two insights from your use case:

• I need to manually port key DateTime functions
• There’s probably a need for client-side system info modules like Hologram.Client, Hologram.Device, Hologram.Platform, etc. (you’d use something like Hologram.Client.timezone())

Is this blocking you at the moment?

Thanks for the explanation! This is actually further along than I expected already.

It’s a silly little side project and my explorations of what’s possible. It could not matter less in the grand scheme of things.