Zeljko Nesic (Sep 29 2022 at 23:47): Zeljko Nesic (Sep 29 2022 at 23:47):I was reading this: https://github.com/roc-lang/roc/blob/15eb36e4ab76e5253ecd2bfc9dc490c0ac6459f6/examples/interactive/cli-platform/FileMetadata.roc#L27
When it came to me that there was no discussion about this _very_sensitive_topic_ .
Namely how do we express clock values and fuzzy concept of time in core library and what part is left to the platform?
Brendan Hansknecht (Sep 30 2022 at 00:24):The core library definitely can't expose a method to get the time. But we definitely could create standard formats and methods to process time.
Brendan Hansknecht (Sep 30 2022 at 00:25):Not sure what the advantage would be over packages with time formats and functions though.
Zeljko Nesic (Sep 30 2022 at 00:40):It can be a package, my point is that there might be better design right away to have a platform agnostic library, which many different platforms implement. Now that to be a standard, ... it is useful to be in a standard library .
Qqwy / Marten (Oct 03 2022 at 17:55):In Elixir there were no standardized date/time/datetime formats for a long time. (Though you could use the functions from the Erlang standard library that essentially are like Date : (U32, U32, U32)).
But at some point there were a handful of different date-time related libraries that had similar but incompatible datatypes.
So at that point the decision was made to extract a minimal subset of this functionality to the Elixir standard library proper, to ensure that the various libraries were able to use a common datatype and approach to conversion.
Kevin Gillette (Oct 29 2022 at 14:21):Whomever designs a module(s) for date/time/calendar should at least be aware of the effort the JS community is making to both correct their own past fundamental design mistakes and end up with a solid internationalization outcome (https://github.com/tc39/proposal-temporal).
For example, whether or not Roc bundles support for non-Gregorian calendar systems, we may be able to, through relatively minor effort, allow alternate 3rd party calendar implementations to interoperate with the stdlib.
We might also survey how different different languages have experimented with parsing and formatting (the classic C style approach has known limitations).
I recommend we don't treat date and time handling as an unimportant part of Roc, as time handling can easily become a pain point for users of a language. Consider Python's two (three?) overlapping official time packages and it's decade-long lack of support for timezones; or Go's robust time representation (nanosecond precision with billions of years range and transparent monotonic clock support) sadly counterbalanced by its somewhat haphazard parsing/formatting style (intuitive or wildly unintuitive, depending on who you ask, and which sidesteps some issues with the strftime yet introduces others); or Elm's relative non-attempt to address time at all.
Date/time/calendrical APIs are not usually one of those areas where a small group of people can ponder in isolation and come up with something that will stand the test of time, unless of course they survey and consider carefully the variety of attempts that have been made to do this elsewhere, and where they've succeeded or done poorly.
Richard Feldman (Oct 29 2022 at 15:53):what would you say is the best API out there for this? (In any language)
Kevin Gillette (Oct 29 2022 at 16:16):I can look into it and make a recommendation, but my point is mainly that, since time is hard, we'd benefit from the scrutiny of many people in this particular area
Georges Boris (Oct 29 2022 at 16:17):I know the Elixir community has also standardized community driven packages somewhat recently into their official Calendar/DateTime packages.
Though I can't comment on the quality of the approach (don't know enough about this domain) - they've gone through the synthesis process so it should be worth looking as an example.
Anton (Oct 29 2022 at 16:33):Would we not always get the (date)time from a platform?
Kevin Gillette (Oct 29 2022 at 16:37):Sampling time from the platform (and scheduling) are only one part of time and date handling. Parsing, formatting, arithmetic, querying ("is date x a Thursday?"), and type representation, all wouldn't (and arguably shouldn't) need to depend on the platform at all.
Georges Boris (Oct 29 2022 at 16:40):@Kevin Gillette depends if we're also talking about timezones changes, right? then we would need access to an IANA table or something like that - which would need to come from a platform.
Kevin Gillette (Oct 29 2022 at 16:45):that can be cached or provided to roc in a bundle of some kind
Kevin Gillette (Oct 29 2022 at 16:45):so certainly facilitated by the platform perhaps, but not necessarily something that should need round-trips to the platform for each operation
Kevin Gillette (Oct 29 2022 at 16:46):roc itself could also embed fallback timezone data, which could be amended by the platform
Kevin Gillette (Oct 29 2022 at 16:47):Roc should intrinsically know about UTC without platform support, at least
Last updated: Jun 16 2026 at 16:19 UTC