date-fns

date-fns copied to clipboard

It seems as if the parse function would not parse strings in a strict way. When for example using parse('2019-12-31T23:24:25.00', 'yyyy-MM-dd\'T\'HH:mm:ss.SSS', new Date()), I would expect parse to assert because there the milliseconds only have 2 instead of tree digits. I'm not sure, if this behavior is a bug or on intended? If it is intended, I would be looking for some way to strictly parse date strings. I'm currently evaluating to move from momentjs to data-fns and in momentjs there is a boolean flag that indicates if a string should be parsed strictly or not.

Exactly the same situation. I have to hold migration from momentjs, though I really want to. I expect isValid(parseISO("13 2020-03-31T16:00:00Z")) to be false rather than true.

The parse() or parseISO() on string input is forced by a warning. However, the parsing result comes to another date rather than the original info.

Similar issue with strict mode: parse('19-06-15', 'yyyy-MM-dd', new Date()); in strict mode should return an invalid date.

Anything new in the topic?

@studnik18 what exactly do you want to know?

If there'll be a strict parse flag in some future release - just wanted to 'refresh' this thread. I find date-fns a very viable alternative to bloated moment.js and this feature comes in handy in some cases.

Same here. Gave the topic starter another thumbs up. This is the only thing that's still missing.

@kossnocorp I would give it a try myself, but have a few questions:

1. Is someone already working on this or planning to do so?

2. There seems to be an ongoing effort to migrate to TypeScript and I'm not sure if I should wait and how long this might take?

3. I would currently plan to implement this as follows:

• Only change the API of the parse function by adding a strict property to the options that can be set to true
• If the the strict flag is enabled, I would change the parser (src/parse/_lib/parsers/index.js) to check for the exact length of each token.
• Add unit tests for strict mode

Bump this. We also have need for strict parsing/matching and would love to see this implemented as a part of date-fns.

agree on this, really causing a lot of headache not having strict

I did prepare a prototype for strict parsing in May but unfortunately never received any feedback.

This isn't an optimal implementation, but you could hack it:

function parseStrict(...args: Parameters<typeof parse>): Date {
  const date = parse(...args);
  if (isValid(date) && args[0] === format(date, args[1])) {
    return date;
  }
  // Do what you want here
  throw new Error("Not a strict match");
}

I'd like to offer my support of making a strict mode available in the parse function or having a stricter match function. Currently it is hard to migrate away from momentjs with an implementation like: moment('010120',['D M YYYY', 'DMYYYY'], true);

Also the isMatch function is not a real viable option without making the code bloated cause the following comes back true isMatch('010120', 'ddMMyyyy')

@HaroldSchouwen I offered my help 1,5 years ago but never received any feedback. I hope you have more luck and will soon be able to get rid of my hacked version.

I need this a lot also, I cannot easily get rid of momentJs without it. Thanks!

A work around to add strict parsing/matching/validating:

const date = '20230502';
const expectedFormat = 'yyyyMMdd';
const parsedDate = parse(date, expectedFormat, new Date());
const isValidDate = isValid(parsedDate) && format(parsedDate, expectedFormat) === date;

Change expectedFormat to fit your requirements. Try it out and let me know if it works for you :).

This type of trick, suggested by @judeamos and @goatyeahh, brought us many issues with timezone in daylight saving dates.

So, unfortunately, is not a viable option right now.

I'm also interested in the non-strict variance that MomentJS has. I tried migrating from MomentJS to date-fns but unfortunately had to pause the migration because of this missing non-strict mode. For example providing a date like 2020-03-01 14:02:03 with a format of yyyy-MM-dd (notice the missing time section in the format) is returning null when parsed in date-fns but works totally fine in MomentJS.

// date-fns returns `null`
const dateFns = parse('2019-05-01 02:36:07', 'yyyy-MM-dd'); 

// moment returns a valid Date + Time in local time zone
const dateMoment = moment('2019-05-01 02:36:07', 'YYYY-MM-DD', false ); 

do you guys know of any alternatives that could allow me to keep going with my migration? Because without this, I simply cannot migrate, I also tried migrating to DayJS some time ago but it has other problems too, also both DayJS and Luxon aren't ESM friendly which is a big no no for me, so for all these reasons I'm stuck with MomentJS still :( ...unless you guys have alternatives to this non-strict problem?