Proposal-temporal: Review leap day support in MonthDay

[Ms2ger]

I feel like we should be able to create a MonthDay object for 29 February. What I'm less clear about is how we should handle plus/minus/difference. Thoughts / precedents?

[kaizhu256]

what are the scenarios for leap-day in MonthDay? pretty much any leap-day scenario i can think of in javascript would use Date or DateTime instead.

i might even go as far to say MonthDay should be removed, due to lack of real-world javascript-scenarios.

[Ms2ger]

I imagine you could use it for storing birth days or anniversaries in your list of contacts, when you don't know the year. I have no strong feelings on whether it should be part of v1.

[kaizhu256]

I imagine you could use it for storing birth days or anniversaries in your list of contacts, when you don't know the year.

you don't need Temporals to fetch/store MM-DD isostrings between UI's and datastores.

[ljharb]

No, but you also don’t want to be passing around naked strings. Being able to use a branded Temporal object with methods is preferred.

[gibson042]

MonthDay should absolutely include February 29, because otherwise it wouldn't be able to support the birthday/anniversary/etc. use cases for which it exists. And MonthDay arithmetic (if supported) should consider or not consider it as specified by a disambiguation parameter, e.g.

MonthDay.from("02-28").plus({days: 1}, "later");    // March 1 (default behavior)
MonthDay.from("02-28").plus({days: 1}, "earlier");  // February 29

MonthDay.from("03-01").minus({days: 1}, "earlier");  // February 28 (default behavior)
MonthDay.from("03-01").minus({days: 1}, "later");    // February 29

We will also need to account for the leap day frequency, such that no two leap days can be less than four years apart and every 400-year interval contains exactly 97 leap days (e.g., {months: 47} considers precisely the same _single_ hypothetical leap day as {days: 1}).

[kaizhu256]

@gibson042 the scenario you presented (w/o a year-context) is unrealistic. the more likely scenario will always contain a year-context:

var anniversary = "02-28";
Date.from("2019-" + anniversary).plus({ days: 1 }); // March 1
Date.from("2020-" + anniversary).plus({ days: 1 }); // February 29

[gibson042]

Agreed, and it would be viable to reject MonthDay arithmetic altogether. But if Temporal supports it, then it should do so fully.

[littledan]

Do folks think it would be OK to insist a year be attached to do arithmetic? That is, MonthDay would simply lack plus and minus methods.

[Ms2ger]

That would work for me as well. Note that (03-01).difference((02-28)) is also not well-defined.

[ryzokuken]

@Ms2ger yeah, I guess we should get rid of the difference method too.

[kaizhu256]

No, but you also don’t want to be passing around naked strings. Being able to use a branded Temporal object with methods is preferred.

i suspect web-projects that message-pass branded MonthDay objects will have more bugs/tech-debt (from needless abstractions) than web-projects that message-pass naked MM-DD isostrings.

[ljharb]

It is entirely possible that that is true, however in my experience, the opposite is true.

[pipobscure]

I'd personally got with #264 and scrap them entirely.

[pipobscure]

In line with the comments above: Presuming we go with keeping them around (they are quite useful) I'd agree that date-arithmetic should not be supported.

[pipobscure]

Oh and just for completeness. Temporal.MonthDay always supported Feb-29; except for arithmetic it assumed a non-leap-year.

[sffc]

I agree with the conclusions in this thread. Any intelligent operations like arithmetic need the year in order for calendar math to be correct.