Good find! This issue is spot on, Time.here is indeed actually Time.hereAndNow.
I’ve pondered this issue for a few days and there are a few options from what I can understand:
1. Let the backend provide the timezone offset and every change reasonably far from now(), both future and past. Feed it to Time.customZone.
Doable but fiddly as you say. Could use the min and max timestamp from the database result to know what a reasonable timeframe is. Not the most attractive solution in my opinion. The request must include a timezone (i.e. “Europe/Stockholm”), a logged-in user setting, or a fallback. Intl.DateTimeFormat().resolvedOptions().timeZone is supported in all evergreen browsers.
2. Let the backend respond with a tuple of timestamp and offset instead of just the timestamp.
Maybe a bit simpler at the first glance. Again, the request must include a timezone (i.e. “Europe/Stockholm”), a logged-in user setting, or a fallback.
3. Let a port calculate the correct offset for every timestamp
Doable but it seems like too much work, I would prefer to have the offset included in the decoded response instead of running every entry through a port as an afterthought.
4. Hand the timestamp off to a custom element like github/time-elements
The most attractive option to me right now. Intl has enough support for my use case and I like the idea of letting the browser do the hard part. The backend can stay completely unchanged. Unfortunately, github/time-elements only seem to handle ISO 8601 timestamps. The first thing they do though is to transform the string into a UNIX timestamp. Most probably their backend returns timestamps as ISO 8601.
Any feedback or more ideas?