Allow 0-6 decimal places of sub-second precision in DateTime type

[obi1kenobi]

I'd like to propose allowing more flexibility for decimal seconds on the DateTime type, allowing it to accept or output between 0-6 digits after the decimal point, i.e. down to microsecond precision. Here is my rationale:

• Different systems and languages by default support different numbers of decimal seconds: OrientDB by default supports only integer seconds (i.e. 0 decimal places), and others like Python support up to 6 decimal places (microseconds).
• If we prescribe a single, fixed number of decimal places and mandate it for all use cases, no matter what number we pick, we will always make someone unhappy about their use case being unsupported. This may lead to a proliferation of competing DateTime standards, and that's something we would probably all prefer to avoid.
• Parsing and rounding rules for additional decimal places are reasonably straightforward to implement, and would not add too much complexity to the spec. If a system expects more precision than is provided, we effectively pad the input with zeroes without changing the semantics. If a system is provided more precision than it supports, it can round to the nearest value it supports, which is guaranteed to be no more than half a second away from the input.

[andimarek]

thanks for the feedback. RFC 3339 allows unlimited fractions of a second which is not a good thing for a spec. This is why the restrictions to 3 digits (milliseconds) was chosen.

I also decided to make it non optional to allow fo easier parsing.

Milliseconds is a reasonable comprise in my experience: I have rarely seen the need for sub millisecond precision in an API, but just seconds is clearly not enough.

The goal is not that all people use this spec: it is not part of the official GraphQL spec exactly because it is really hard to satisfy all requirements.

The overall goal is that this DateTime spec will be good for the vast majority of uses cases and serve people well who get started with GraphQL.

Can you give more concrete examples for APIs which require RFC3999 formatted values with micro or nano second precision? thanks a lot

[SeijiSuenaga]

This issue is old, but I just want to throw my use case in here as an example.

I have APIs that have supported REST for years, and they provide a lot of existing data that was persisted with 7 digits of precision. Now I'm adding GraphQL support, and I want both paths to return timestamp values using the same precision.

To make my REST and GraphQL data consistent, I could reduce precision of the REST path, but retroactively changing existing representations would be problematic. So I'll probably have to increase precision of the GraphQL path by using a different type than the graphql-scalars DateTime.

[dondonz]

Hello, letting you know we continued on with the scalars work in a new repo https://github.com/graphql/graphql-scalars

It's totally fine to have a different precision, and you're free to write your own specification. In the GraphQL Java extended scalars library, we have kept it to 3 digits of precision.