massivefermion / birl

datetime handling for gleam
https://hex.pm/packages/birl
Apache License 2.0
72 stars 9 forks source link

Set date from small to large time unit #32

Closed ofekd closed 5 months ago

ofekd commented 5 months ago

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:

const date = new Date(); // May 31st, 2024
date.setUTCFullYear(2024); // Still May 31st, 2024
date.setUTCMonth(5); // No such thing as June 31st, sets to July 1st
ofekd commented 5 months ago

My first solution foolishly had the opposite problem. I've pushed an updated version.

massivefermion commented 5 months ago

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?

ofekd commented 5 months ago

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")
massivefermion commented 5 months ago

yeah, makes sense. Thanks for the PR.