Closed ofekd closed 5 months ago
My first solution foolishly had the opposite problem. I've pushed an updated version.
I understand the issue you mention but I still don't see how your PR fixes it. Whether you give the numbers separately or together, the behavior is the same, isn't it?
Also, could you explain how does this manifest itself when used from Gleam? Could you provide an example in Gleam that has this problem?
The problem is not setting an impossible date but having an impossible date carried over from today's date.
If today is May 31st, and I try to get a new date object to be June 1st, this will fail:
const date = new Date(); // May 31st, 2024, today's date
date.setUTCFullYear(2024); // Still May 31st, 2024
date.setUTCMonth(5); // No such thing as June 31st, sets to July 1st
date.setUTCDate(1); // July 1st, not what we were looking to get
This will work:
const date = new Date(Date.UTC(2024, 5, 1)); // June 1st
Edit:
A Gleam example would be, but only on JS target:
// With birl 1.7, If you run this on May 31st, this will parse as July 1st, not June 1st
birl.parse("2024-06-01T00:00:00.000Z")
yeah, makes sense. Thanks for the PR.
This avoids ambiguous situations where the desired month does not have as many days at the current month, leading to unexpected behavior.
For example, intending to create a date in June on the 31st of May, will result in the date being in July instead: