Missing methods from "date-fns"

[hazem3500]

I was using "date-fns" and wanted to move to use "date-io" interface but I found a couple of methods that I am using are missing.

Methods

• isDate
• addYears can be substituted with addMonths(date, 12)
• subMonths can be substituted with addMonths(date, -1)
• subYears can be substituted with addMonths(date, -12)
• getWeek
• getQuarter
• setQuarter
• min
• max
• differenceInCalendarDays
• differenceInCalendarMonths
• differenceInCalendarYears
• startOfQuarter
• startOfYear
• isSameQuarter
• parseISO
• getTime
• getDay
• getDate

I know that some of these methods can be achieved by using other methods in the current interface but am not sure how to handle the ones that aren't.
I am not sure if adding these methods to the interface is the best option since it will increase the API surface, what do you guys suggest for these kinds of situations?

[dmtrKovalenko]

Hey, thanks for raising this. My question – how you are planning to use date-io? If this really required I can add these methods – it's not a problem.

sub* methods will not be added in favor of negative number addMonth(date, -12)

[hazem3500]

@dmtrKovalenko I am forking react-datepicker and trying to make it agnostic of the date-management library so it can support additional calendar systems.

I ended up creating the above functions using the available functions from date-io, it would be great if someone of them were added though.

[dmtrKovalenko]

Awesome! I will add all the required functions, but probably except the

• isDate - makes no sense in cross-lib comparison
• parseISO – ISO strings perfectly parses using new Date() or utils.date()

Give me a few days to make a PR and new version

[eps1lon]

ISO strings perfectly parses using new Date()

That's debateable. new Date(isoString) just like Date.parse are "discouraged"¹ because of browser inconsistencies. Namely Safari assumes UTC when the timezone is missing in the ISO 8601 string while all other browsers assume local time.

date-fns' parseISO resolves these inconsistencies. utils.date should rather use parseISO under the hood if it's used with an ISO date. You can see that in https://cc8j3.csb.app the output of parseISO is consistent across chrome and safari while new Date output is different.

¹ https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Date

[dmtrKovalenko]

Yeah, that's weird. Thanks @eps1lon I will update the logic accrosss all the adapters

[bartvde]

has this been done? I don't see any reference to parseISO in the codebase