Provide default scalars for representing date/datetime in ISO format

[excitement-engineer]

After having used graphql-js for some time I have had a lot of use-cases for scalars that represent a date and datetime. I was wondering what everyone's opinion is on including these convenience scalars in this project.

I realize that these scalars are not part of the graphql-spec and that different people use different date formats. However, I think that a lot of people will have a use case for these types of scalars. In addition, the ISO 8601 format is a very commonly accepted format for representing dates so it should be widely applicable.

I'm interest to hear your opinions on this matter!

[leebyron]

We actually tossed around the idea of including a DateTime scalar in the spec, but decided to start conservatively. I like the idea of introducing an experimental one.

[excitement-engineer]

I'd love to send a PR for an experimental datetime scalar that uses the ISO format! Is it okay if I implement this?

Did you guys also discuss including a date scalar (so without the time) in the spec?

[leebyron]

DateTime should probably include Dates without Times, something the ISO format supports.

Feel free to start a PR if you're interested. We can take a look from there!

[excitement-engineer]

Great, I will give it a try:) Thanks a lot for your help, I appreciate it!

[langpavel]

Hi @leebyron and @excitement-engineer

History show us that there is no Date without (Time or Timezone)...

Most bad thing is date without explicit timezone.

All debates around with or without timezone are problematic because we all have local perception of spoken (=> written into form => stored in DB) time.

For me only acceptable format is timestamp expressed as number of (milli)seconds from (UNIX) big bang.

So, consider real number as one possible input for coercion..

I have something for this theme here: GraphQLTimestamp

[thebergamo]

I like the idea that GraphQL uses DateTime as default scalar, because in all systems, we'll need to express dates or just datetimes. Its a common problem, like using int, strings or whatever you want, so supporting this scalar at core is very important.

Of course, its not so simple as int or string, because is not a common use of it, but basically supporting the ISO date, you as a consumer of this scalar can easily parse all dates with momentjs ezpz without any problems.

Well, that's my 10cents!

[ebridges]

It is actually quite common to consider dates irrespective of a time zone: e.g. when listing holidays in a given year.

Requiring time (and timezones) to always be associated with a date (and vice versa) leads to inconvenient workarounds -- hence the ISO spec granting that flexibility.

GraphQL should support a scalar that simply represents an ISO8601 string. The implementing systems can easily parse any properly formatted string according to their needs (whether that be a Date, a Time, a DateTime, etc.).

If a system prefers to work in unix timestamps it's trivial to convert an ISO8601 to/from same.

[cloudlena]

Why not use RFC 3339?

[smithaitufe]

Please what is the state of this issue?
Has the date feature been implemented?
If so, where do I find the documentation?
If not, what is holding it back?

Thanks

[bygui86]

+1

[langpavel]

@smithaitufe See my comment. Date and time is not easy to express, it mostly depends on context.
Even same system may use different (storage) formats by semantics:

• string representation
• number representing UNIX epoch timestamp in seconds or milliseconds or even nanoseconds.
• even something more customized

I'm using this custom scalar: GraphQLTimestamp

[langpavel]

See also

• Initial proposal for the experimental GraphQLDateTime scalar #557 — Initial proposal for the experimental GraphQLDateTime scalar
• [RFC] Support DateTime scalar graphql-spec#315 — [RFC] Support DateTime scalar

[smithaitufe]

@langpavel

I ended up using that package as well and it has been working great.

[dandv]

@langpavel: plans to make that gist into an easy-to-import npm package, like @excitement-engineer's grapql-iso-date? Or does that package already subsume yours?

[IvanGoncharov]

I think Lee wrote great summary in #557:

I think the conclusion from this PR is that there is not one DateTime type to rule them all. Tradeoffs involved will lead to reasonable different decisions for different APIs.

Having these utility scalar types available in a package on NPM would be highly valuable, but since there isn't consensus on a single one, this package is probably the wrong place to host it. It's been incredibly valuable to work through this discussion in this forum!