Add ChilliCream Date scalar

[glen-84]

No description provided.

[martinbonnin]

I'm curious what are the use cases when you'd want to use Date that are not covered by either DateTime or LocalDate?

[glen-84]

I wasn't involved in the implementation of these scalars, but I think that they align with what The Guild has.

I'm not sure of the exact use cases, but the difference is in the serialization behaviour of DateTimes, which are normalized to UTC. I suppose if you're returning data from external systems, then you may or may not want those DateTimes to be converted to UTC.

[martinbonnin]

The way I see it, there are 2 classes of structures:

1. Absolute instants: indicate a specific point in time. In Java, this is the Instant class. In your proposals, this is DateTime.
2. Human dates: indicate dates whose specific point in time may change (because of daylight saving, regulation changes, etc..)

You go from 2. to 1. by specifying a time zone.

Human dates and times (2.) benefits from having different formats with different precision. For an example, GraphQL Conf 2025 started on "2025-09-08" (LocalDate) but the Keynote started at "2025-09-08T09:00" (LocalDateTime). And the hotal breakfast is served every day starting at "07:00" (LocalTime). The precision and the presence/absence of a date/time is important there.

I'll argue it's a lot less important for instants. Do you need to use "2023-12-24" when you can use "2023-12-24T00:00Z" and make the time and timezone explicit for the reader?

[glen-84]

I checked with Michael, and he said that you'd use Date for something like a birth date (no local context [global]), and LocalDate for something like a contract (with local context [where the contract was signed]).

I'll argue it's a lot less important for instants. Do you need to use "2023-12-24" when you can use "2023-12-24T00:00Z" and make the time and timezone explicit for the reader?

Yes, I would definitely use the date only in a case like this, not only to avoid unnecessary storage, but also to indicate that only the date is meaningful – f.e. there is a time associated with a birth, but it may not be available or relevant.

[martinbonnin]

you'd use Date for something like a birth date

I would use LocalDate for a birth date. The country you're born in is the context. If I share my date of birth, 1981-09-27 without more context, I'd assume most of my contacts to assume the French timezone. If I want to carry the exact time I was born for legal reasons, I would use something like 1981-09-27T00:14:00+02:00

not only to avoid unnecessary storage, but also to indicate that only the date is meaningful – f.e. there is a time associated with a birth, but it may not be available or relevant.

Then why not use LocalDate? My date of birth is 1981-09-27. Feels weird to send it as 1981-09-26 because some intermediary wants to align everything to UTC.

[glen-84]

This is all quite abstract to be honest. 🙂

The use case I think of is a website that asks for your DoB (let's say for age verification). You enter 1981-09-27 and I enter 1984-01-09. You now have two dates in the database, each with their own local context, but there's no way to know the local context (unless you also selected your location/TZ, which might not be the case).

If you use Date, you completely ignore local context, and just think about the date itself. If these dates came from an external system which happened to also include the TZ offset, then you convert them all to UTC so that they don't each represent dates in a different local context (context which is now lost). With dates normalized to UTC, you could then format them in a local TZ if needed.

In other words, if you see the date 1984-01-09, how do you know which TZ this date is associated with? It's okay if you know that all dates are in the French TZ, but in this case they have different TZs, so you lose that information unless you either normalize it (to French or UTC), or store the TZ as well for each date.

Not sure if this makes sense, or even if my interpretation is accurate. 🙃

[martinbonnin]

Ah, that's an interesting case! I'd say websites which ask for age verification do so to comply with countries regulations and should use at least geo-ip to attach context to the user dates.

Interestingly that doesn't work really well, so France decided to go through a 3rd party age verification provider where you have to upload your ID.

Precise dates would require LocalDatetime IMO. Other purposes, such as online stores sending you spam a marketing email for your birthday should store the timezone alongside your date of birth. They know your currency/country already. I'm almost sure French people living in Guyana will get their marketing email a few hours too early but no one cares... ^^

All in all, I don't need both Date and LocalDate I'll use LocalDate always.

[glen-84]

@martinbonnin Ready for merge.