Skip to content
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

Open
ear7h opened this issue Jun 14, 2021 · 4 comments
Open

Handling TOML timestamps #2220

ear7h opened this issue Jun 14, 2021 · 4 comments

Comments

@ear7h
Copy link
Collaborator

ear7h commented Jun 14, 2021

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. But dhall-to-toml requires some mechanism of distinguishing strings from timestamps since the syntax for times are different:

a-string = "1970-01-01"
a-time = 1970-01-01

In the above thread one approach mentioned is to use a newtype { date : Text } to represent times, but overloading a record with a date field seems like it would run into problems. I think a better approach, with a similar effect is to use an enum Date : Type = <Date : Text>. This could live in the prelude under Prelude.Toml.Date. However, it requires special-casing the type in dhall-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.

@sjakobi
Copy link
Collaborator

sjakobi commented Jun 15, 2021

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 { date : Text } or maybe { tomlDate : Text }. The < Date : Text > idea is nice too, but I think it's a bit less convenient to extract the field from it.

The main precedent for types that carry special meaning during marshalling is the JSON.Nesting type used in dhall-json.

How do the Haskell TOML libraries handle TOML's dates and times BTW? That might give us some inspiration.

@ear7h
Copy link
Collaborator Author

ear7h commented Jun 15, 2021

Both tomland and toml haskell packages use the time package, where the types are records. For example UTCTime is:

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:

  • offset datetime (has a time zone)
  • local datetime (no time zone)
  • local date (no time zone)
  • local time (no time zone)

So there would actually need to be multiple newtypes { offsetDatetime : Text}, {localDatetime : Text}, etc. I was thinking that a single { tomlDate : Text} would work, but the the date kind is necessary in for making the correct Toml.Codec value

@Gabriella439
Copy link
Collaborator

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)

@sjakobi
Copy link
Collaborator

sjakobi commented Aug 12, 2021

For reference:

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants