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

Month Day Format #1970

Closed
rubber-duck-software opened this issue Dec 10, 2021 · 3 comments
Closed

Month Day Format #1970

rubber-duck-software opened this issue Dec 10, 2021 · 3 comments
Labels

Comments

@rubber-duck-software
Copy link

I would like to make the case that 07-04 is a poor format for month day. This could just as easily refer to April, 2007 as July 4th. The alternative format --07-04 makes clear that the year field is being omitted. Why should this namespace emit the less clear format on this?

One place this is already causing inconvenience is related to typescript typing. One can easily establish a typescript type which can differentiate between date strings, date time strings, instant strings, etc. But one cannot differentiate between YearMonth and MonthDay. Both have the template string

type yearMonthString = `${number}-${number}`
type monthDayString = `${number}-${number}`

Please consider revising this

@ljharb
Copy link
Member

ljharb commented Dec 10, 2021

YMD is the only way things should be represented, for all sorts of reasons, so it should be only understood to mean July 4th.

As for YearMonth vs MonthDay, these are Temporal objects with an identity, and it’s just fine that the TS type for the string form is the same. If you want to differentiate, you’d use nominal typing.

@ptomato
Copy link
Collaborator

ptomato commented Dec 10, 2021

We don't have any two-digit years allowed anywhere in any string format emitted or accepted by Temporal, so in that sense it's not ambiguous. But I agree that just the MM-DD string format viewed in isolation may be ambiguous.

I was going to say in case of ambiguity you could pass { calendarName: 'always' } as an option to toString(). But that currently produces 07-04[u-ca=iso8601] for the ISO calendar, without the reference year, and I can't remember if leaving out the reference year was intentional or a bug. (For other calendars it always prints the reference year.) So I'll have to investigate that.

I have to admit this is the first time I learned about template literal types in TypeScript! I agree with Jordan that probably it's better to use the Temporal objects in your API rather than typed strings. But if you have to use typed strings, it'd probably be worth narrowing down the types. If I understood correctly my quick read of the TypeScript docs on template literal types, you could do that like this:

type Digit = '0' | '1' | ... | '8' | '9';
type YearString = `${Digit}${Digit}${Digit}${Digit}`;
type MonthString = '01' | '02' | ... | '11' | '12';
type DayString = '01' | '02' | ... | '30' | '31';
type YearMonthString = `${YearString}-${MonthString}`;
type MonthDayString = `${MonthString}-${DayString}`;

(Note that this doesn't cover everything that would be accepted by Temporal APIs that take year-month strings or month-day strings: like extended years, and basic format without dashes. Depending on your application, these types may or may not be sufficient!)

@ptomato
Copy link
Collaborator

ptomato commented May 10, 2022

Thanks for leaving your feedback on the proposal, I'm closing the issue now.

@ptomato ptomato closed this as completed May 10, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants