Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

parse with format mmm yyyy fails #36

Open
Rauskii opened this issue Jul 29, 2019 · 1 comment
Open

parse with format mmm yyyy fails #36

Rauskii opened this issue Jul 29, 2019 · 1 comment

Comments

@Rauskii
Copy link

Rauskii commented Jul 29, 2019

When trying to parse a string 'Feb 2019', using
Timeliness.parse('Feb 2019', format: 'mmm yyyy')
it returns nil, if the current date is something that does not exist.
For example I was trying to parse above Feb 2019 string on 29th day of July, and parsing it apparently fails as there is no 29th day in february 2019.
Same issue might happen when trying to parse lets say 'April yyyy' during 31st day of some month.
Could the 'mmm yyyy' format parsing default to first day of the month instead of returning nil on these rare cases?

@adzap
Copy link
Owner

adzap commented Jul 30, 2019

One of the goals of this gem is be more strict or 'correct' than the native Ruby Time behaviour. I would not consider your suggestion to be necessarily correct. The expected behaviour of this format is ambiguous and I don't think I want to change the current behaviour as it is consistent.

What I think is the best way forward is to improve the default date parts handling. At the moment the date parts can be configured for when a time type value (time only string) is being parsed so that a Time object can be returned. I think expanding this behaviour to allow you specify default date part values when they are not specified in a format for date, time, or datetime types.

I have no timeline for this at present.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants