search

andrewplummer / Sugar

A Javascript library for working with native objects.
https://sugarjs.com/
MIT License
4.54k stars 305 forks source link

"Mar 3" > 3/3/2018 (current year-good!) BUT... "Mar-3" > 3/3/2001 (bug) #630

Open khakman opened 6 years ago

khakman commented 6 years ago

Love sugar! We are using it on TeamworkIQ.com. Our users love it too.

However, our users found a bug... and I verified the bug this morning using https://sugarjs.com/docs/#/DateParsing

If you parse the date phrase "Mar 3" you'll get March 3 of 2018, the current year. That's good! Same is true for "3 Mar"

However...

If you use the date phrase "Mar-3" ( with a - dash ) you'll get March 3 of 2001. That's a bug. Same bug is true for "3-Mar".

Seems for the format "dd-mmm" and mmm-dd" return the wrong year. Seems they should behave the same as other phrases which omit a declared year ... and in that case by default the parser returns the current year (unless other SugarJS configs instruct SugarJS to do otherwise).

Thanks. Let us know if there's any way we can help further with the resolution of this bug.

andrewplummer commented 6 years ago

Thanks for this! I'll have a look into it but at first glance this looks like a case of Sugar not recognizing the format and falling back to native date parsing. For the next version I'm considering not doing this as I get a fair number of tickets where this is unexpected. This in fact may be a Sugar bug and I'll look into it as such, but what do you think about the idea of not falling back to native Date parsing?

khakman commented 5 years ago

I'm not sure of the impact of NOT falling back to native date parsing. SugarJS covers so many cases, I'm unsure which would fail if you did that and as such an not well prepared to offer an opinion.

However, you could... add a flag to the returned result when native date parsing IS used. This at least could let your users know, and if desired, take action to double check accuracy.

andrewplummer commented 5 years ago

I think the impact of not falling back would essentially be minimal for English, however other locales may be more affected where I'm not as confident in the format coverage. More importantly though, not falling back would allow the option to fall back as needed.

In any case, thanks for the feedback! Will be thinking about it.