Time.here is missing eras

[sldab]

Problem

Time.here captures the current timezone offset with an empty eras list [].

Impact

When you're in CET (UTC+1, winter), it creates a zone fixed at +60 minutes. Displaying a summer date (which should use CEST, UTC+2) still uses +60 minutes => off by one hour.

Proposed solution

Get the user's timezone with past and future DST era information in the Kernel's JS code by scanning monthly from 1970 to 2100 and calling getTimezoneOffset() repeatedly to detect DST transitions:
https://github.com/gren-lang/core/blob/main/src/Gren/Kernel/Time.js#L25C1-L33C2

[robinheghan]

This code is originally from Elm, and when it was written there was no way to reliably retrieve DST era information from the browser. Has that changed? We ideally don't want to ship it as part of the core packages to avoid the work involved in keeping that information up to date and to avoid uneccessarily increasing bundle size.

[sldab]

I regard the current Time.here function as highly problematic because it can easily introduce subtle and hard-to-detect bugs.
Gren's philosophy strongly emphasizes correctness. The current implementation contradicts the philosophy of designing for clarity, safety, and correctness. Therefore I believe there should be a better implementation.

I agree that bundling the IANA time zone database is a no-go. There is still no direct access to it, but at least it's more convenient to retrieve time zone information with the new Temporal API.
The getTimeZoneTransition("next") method on the Temporal.ZonedDateTime object allows us to fetch the next (or previous transition). This is a cleaner approach than my original proposal using getTimezoneOffset().

We could use it to add a Time.hereWithTransitions fromYear toYear function to the Time module. The Javascript part would collect all transitions calling the getTimeZoneTransition("next") method repeatedly in the given interval. This would not add much to the bundle size.

Caveat

As of now the Temporal API is only available on Chrome, Edge and Firefox. But as the Time.hereWithTransitions function would be a Task, one could easily call Task.attempt and fall back to Time.here in such cases or use a polyfill.

If interesed I can provide a PR for this.

[robinheghan]

I regard the current Time.here function as highly problematic because it can easily introduce subtle and hard-to-detect bugs.
Gren's philosophy strongly emphasizes correctness.

I agree. I was just providing context.

Is it possible to represent Time.here using a special value, and only figure out the timezone offset at the last possible minute?

[sldab]

I don't know if I got you right, but I think this would just solve the issue with the current time, not with historic or future times.

The more i think about it, the more i come to the conclusion that it would be better not to carry any timezone calculation information around in gren and instead make Zone an opaque type that just wraps the IANA timezone identifier string.
Time.here would just call Intl.DateTimeFormat().resolvedOptions().timeZone ?? "UTC".
Time.customZone would be dropped.

This would also allow us to have something like Time.supportedZones that would call Intl.supportedValuesOf("timeZone") and wrap them all into a Set Zone.

Next, all Human Times functions like toYear, toMonth, toDay etc. in the Time module would accept the opaque Zone type as their parameter and call a Kernel implementation in Javascript that relies on Intl.DateTimeFormat to do the work for it.

It just doesn't make sense to do timezone calculations in the Time core module without full access to the IANA database.

What do you think?

[robinheghan]

It sounds reasonable. I'd like to get some more feedback before giving it the go-ahead, though. Just in case :)

[sldab]

Sure, makes sense.

One issue that I see so far is that Intl.DateTimeFormat could throw a runtime exception if the IANA database in the browser is messed up. Also, it returns strings which must be parsed to numbers. This could go wrong as well.

Thus, I propose to replace the fine-grained human times functions like toYear, toMonth, toDay with a single function:

Time.toDateTime : Zone -> Posix -> Result Error DateTime

type TimePrecision
    = Seconds
    | Millis
    | Micros
    | Nanos

type alias DateTime = {
    { zone : Zone
    , precision: TimePrecision
    , year: Int
    , month: Month,
    , day: Int
    , weekday: Weekday
    , hour: Int
    , minute: Int
    , second: Int
    , millis: Int
    , micros: Int -- 0 if precision is Millis (Intl.DateTimeFormat)
    , nanos: Int -- 0 if precision is Millis (Intl.DateTimeFormat)
}

And fill it in one run of:

  const formatter = new Intl.DateTimeFormat(locale, {
    timeZone,
    year: "numeric",
    month: "2-digit",
    day: "2-digit",
    weekday: "short",
    hour: "2-digit",
    minute: "2-digit",
    second: "2-digit",
    hourCycle: "h23"
  });

  const parts = formatter.formatToParts(date);

On browsers that support the new Temporal API it's cleaner. It returns numbers and supports micros and nanos. We could try it first and fall back to Intl.DateTimeFormat.

  const zoned = instant.toZonedDateTimeISO(timeZone);

  return {
    year: zoned.year,
    month: zoned.month,
    day: zoned.day,
    weekday: zoned.dayOfWeek,
    hour: zoned.hour,
    minute: zoned.minute,
    second: zoned.second,
    millis: zoned.millisecond,
    micros: zoned.microsecond,
    nanos: zoned.nanosecond
  };

[robinheghan]

What if, instead of a Zone being an opaque IANA timezone identifier, we make it an opaque Intl.DateTimeFormat instance?

This way, creating the Zone is failable, but human time functions should still be pure (I'm fine with trusting parseInt to work).

I'm fine with a Time.toDateTime like function, but a better name might be Time.toParts?

[robinheghan]

We probably also want something like Zone.toId and Zone.fromId. I can imagine people having the need to store the Zone information by sending it over the network or storing it in local storage, or something like that.

[sldab]

I like Time.toParts. It sounds concise and does not create confusion. Zone.toId and Zone.fromId make sense, too.

I'm not sure if we should trust Intl.DateTimeFormat, though. Even if its instantiation succeeds, the formatToParts method can still fail. There have been bugs like this in the past: formkit/tempo#80.
Also, Time.supportedZones would create a lot of Intl.DateTimeFormat objects. It's not a big deal (takes 1 - 3 ms on my notebook), but it doesn't feel right. But reusing a (single) Intl.DateTimeFormat instance would be a good idea. It is thread-safe.

[robinheghan]

There have been bugs like this in the past: ...

We can't take it upon ourselves to work around potential bugs in the underlying runtime. In the linked bug it said that it didn't happen if you chose numeric instead of 2-digit, so that seems like a decent workaround.

Also, Time.supportedZones would create a lot of Intl.DateTimeFormat objects.

I think we first have to aim for correct semantics. Memory use and performance can be optimized later if they prove to become problematic.

I don't want to return a Zone unless we can be certain that it won't throw a runtime error later.

I guess we don't need to construct DateTimeFormat objects when using Time.here and Time.supportedZones, as we're either using UTC (which should always be available) or using a value that comes directly from the runtime. But in the case of Time.fromId we definatly need to verify that the id is correct, and I believe the only way to do that is by constructing a DateTimeFormat object?

I guess that means we can use the string as the actual Zone value, and use DateTimeFormat to validate before creating a Zone.

[sldab]

We can't take it upon ourselves to work around potential bugs in the underlying runtime. In the linked bug it said that it didn't happen if you chose numeric instead of 2-digit, so that seems like a decent workaround.

Fair point. But I just found out that Intl.DateTimeFormat.formatToParts treats numeric like a hint, not like a strict requirement. Its outcome depends on the given language code, whether this language is available in the browser, the calendar and it may differ from browser to browser. Test this:

const df = new Intl.DateTimeFormat("zh", { 
  calendar: "chinese", year: "numeric", month: "numeric", day: "numeric" 
});
df.formatToParts(Date.UTC(2026, 02, 20, 12, 58, 31));

I get Chinese signs for the month. I did use the Chinese calendar here, but still. I'd really prefer toParts to return a Result type.

I don't want to return a Zone unless we can be certain that it won't throw a runtime error later.

The compiler already requires Node v20, so we can use

Intl.supportedValuesOf("timeZone").includes(zoneId);

Browsers don't do live updates of the IANA database, so we can assume that a zone doesn't suddenly disappear.
As said, errors in Intl.DateTimeFormat.formatToParts still can't be fully ruled out, though.

Concerning the Zone module we would have this, right?

• Zone.fromId (Result)
• Zone.toId
• Zone.here (Task) -- moved from Time.here
• Zone.all (Task)? -- instead of Time.supportedZones.

What about calendar support? We would need

• Calendar.fromId (Result)
• Calendar.toId
• Calendar.here (Task)
• Calendar.all (Task)? -- using Intl.supportedValuesOf("calendar")

The M̀onth type would be dropped and changed to Int as its range differs across calendars. I don't see any benefit in it anyway. It just makes months cumbersome to work with.

The Weekday type can stay. It actually makes sense.

Considering precision: I think micros should be sufficient. We could add microsecond precision later when switching the Posix type to BigInt. nanos would limit us to the year 2262 when stored as BigInt.

Time.Parts would now be

type alias Parts = {
    { zone : Zone
    , calendar: Calendar
    , year: Int
    , month: Int,
    , day: Int
    , weekday: Weekday
    , hour: Int
    , minute: Int
    , second: Int
    , millis: Int
    , micros: Int
    }

Time.toParts : Calendar -> Zone -> Posix -> Result Error Parts

Intl.DateTimeFormat can fill all those fields for every calendar even if the calendar doesn't have the concept of weekdays or if the concept of months differs, but we need to call it with a fixed locale that leads to numeric formatting and is available in most browsers like en-US. The conclusion here for me is to use the Temporal API when available (predictable as it produces numbers) and use Intl.DateTimeFormat as a fallback only.

For some calendars like the Chinese or Hebrew calendar we would need era and monthCode fields for disambiguity to be able to reconstruct a Posix timestamp from Time.Parts, but those are only available in the new Temporal API.

To fetch both Zone and Calendar, we could add a Browser.environment Task that returns

type alias UserEnvironment = {
    { zone : Zone
    , calendar: Calendar
    , languageCode: String
    }

[robinheghan]

But I just found out that Intl.DateTimeFormat.formatToParts treats numeric like a hint, not like a strict requirement.

Stuff like this worries me 😅

I have to take into consideration that I might be the one having to maintain this moving forward, so I want to make sure we're not creating a new implementation on top of quicksand. Do you think it's possible for us to catch all edge cases here, or are we commiting to a long game of whack-a-mole until the Temporal API gets widely supported?

I get Chinese signs for the month. I did use the Chinese calendar here, but still. I'd really prefer toParts to return a Result type.

I'm not opposed to make toParts return a Result, but it does make the function more of a hassle to use, so if it's possible to avoid it that would be nice. Another thing we need to be worried about is that the underlying kernel code doesn't trigger a side effect that can be noticed through the Result, though I don't think that's the case here.

The compiler already requires Node v20, so we can use

👍

Concerning the Zone module we would have this, right?

Zone.fromId (Result)
Zone.toId
Zone.here (Task) -- moved from Time.here
Zone.all (Task)? -- instead of Time.supportedZones.
What about calendar support? We would need

Calendar.fromId (Result)
Calendar.toId
Calendar.here (Task)
Calendar.all (Task)? -- using Intl.supportedValuesOf("calendar")

This is a much bigger change than the one you originally suggested, and I think a github issue is the wrong place to discuss it. To many conversations where it's easy miss some details.

The Zone stuff we've talked about til now has been a relatively minor change. Do you want to get the underlying Zone changes implemented first, or are you motivated to do a full re-think on how we format time?

In the latter case I'd be much happier with standalone document that explains the new API and intended usage, so that I can see all the changes in one place instead of piecing it together from conversation.

[sldab]

I'd prefer to do a full re-think to avoid changes later on when the Temporal API becomes the new standard.
I will be quite busy in the upcoming days, but I will come back with a full proposal in a single document.

[adamdicarlo]

I recently localized an Elm app and I needed to create a NamedTimeZone type that carried both the Time.Zone and the IANA name of the timezone so that I could format abbreviation strings like PST.

Storing the IANA name for the zone and relying on browser/platform APIs makes sense to me, if it's possible to polyfill Safari support... though providing the polyfill in a way that is dynamically loaded (only when on Safari) is something that might be tricky to do in the actual compiler, unless you're ok with having a centrally-hosted polyfill, or outputting the polyfill from the compiler and requiring it be served alongside the main JS output file.

[note: I deleted a prior comment about compatibility. I had misread a comment above and was just restating it -- Safari is the one missing support]

[sldab]

Yes. The good thing is Safari always has the en-US locale installed, so the Intl.DateTimeFormat.formatToParts fallback will work on it. It's probably just a handful of Chinese browsers that don't have the en-US locale and Intl.DateTimeFormat.formatToParts will fail on them.