Native date / time data types

[asgeirn]

Passing date and time values is an area where there are many pitfalls and intricacies in various programming languages.

Thus I think it would be very helpful for a configuration language to define native types for this with correct bindings.

It should support validations which constrain the valid range for dates and times, and preferably also relative to current time, i.e. value must be in the past / future / at least x days into the future.

[abhibeckert]

I would like to see a time period such as an entire day or a range of hours. With comparisons to check if the current time falls within that period.

[n8felton]

I would like to request that some of the most common Internet DateTime standards should be supported for:

1. Validation
   • Is the date/time format valid?
2. Manipulation
   • Add/Subtract time
3. Conversion
   • If, for example, a pkl configuration only supports the ISO8601 standard for representing DateTime, then allow for conversion to other formats.

References

1. ISO 8601-1:2019
   • 2006-01-02T15:04:05-0700
   • 2006-01-02T15:04:05Z
2. ISO 8601-2:2019
3. RFC 3339
   • 2006-01-02 15:04:05
4. RFC 5322 (previously RFC 822 and 2822)
   • Mon, 2 Jan 2006 15:04:05 -0700
   • Mon, 2 Jan 2006 15:04:05 MST

[asgeirn]

For validation, configuring date and time without time zone information should probably either be illegal or explicitly be interpreted as UTC -- any other interpretation opens the configuration to depend on runtime system configuration.

As long as Pkl correctly represents date/time, for instance in ISO 8601 or RFC 3339, and uses data bindings to the target language, converting to any format usable for the application is "fairly" trivial.

By Pkl ensuring that the specified date/time instant is precisely stated, a lot of causes for errors are eliminated.

[bioball]

This is something we've been considering adding to Pkl for a while.

Some APIs to borrow from:

• Temporal https://tc39.es/proposal-temporal/docs/
• java.time (https://jcp.org/en/jsr/detail?id=310)

If we add this, it should interact with Duration

[holzensp]

A key problem with e.g. adding a Duration to a DateTime (or a DateTime in duration format to another in non-duration format), is that the timezone matters for the meaning; if the sum rolls over daylight savings, that should be incorporated, somehow (and is difficult to get right).

I had an initial attempt a while ago, but stranded a bit in these issues and some UI considerations (there is no now() in Pkl, because it's deterministic; is the right UI to require feeding in a prop:now; etc etc). I dusted it off and put it up if someone wants to take a look and have a stab at moving the implementation along: holzensp/pkl-pantry@fa8f118