-
Notifications
You must be signed in to change notification settings - Fork 214
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Handling TOML timestamps #2220
Comments
I think it does make sense to rekindle the discussion in dhall-lang/dhall-lang#80. The Dhall community has changed quite a bit in the two years since the last comment on that thread. In particular, there are quite a few more implementations that may or may not want to provide built-in support for dates. Until we have a decision on the language support we might as well do the easiest thing which I think is to use a simple newtype like The main precedent for types that carry special meaning during marshalling is the How do the Haskell TOML libraries handle TOML's dates and times BTW? That might give us some inspiration. |
Both data UTCTime = UTCTime {
-- | the day
utctDay :: Day,
-- | the time from midnight, 0 <= t < 86401s (because of leap-seconds)
utctDayTime :: DiffTime
} Something I remembered is that there are different kinds of times in TOML:
So there would actually need to be multiple newtypes |
I wrote up my thoughts on how this could be done as a change to the language standard here: dhall-lang/dhall-lang#80 (comment) |
For reference:
|
TOML has native support for dates and times and I'm wondering how this should be handled in dhall. I can add to the discussion standardizing date/times in dhall, but perhaps a more specialized solution would be better.
I don't think
toml-to-dhall
poses too much of a problem, we can just turn the timestamps into strings. Butdhall-to-toml
requires some mechanism of distinguishing strings from timestamps since the syntax for times are different:In the above thread one approach mentioned is to use a newtype
{ date : Text }
to represent times, but overloading a record with adate
field seems like it would run into problems. I think a better approach, with a similar effect is to use an enumDate : Type = <Date : Text>
. This could live in the prelude underPrelude.Toml.Date
. However, it requires special-casing the type indhall-to-toml
and I'm not sure if that's acceptable or if there's a precedent for doing that in other dhall (en|de)coders.The text was updated successfully, but these errors were encountered: