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

Cant parse a simple date #100

Open
rmasci opened this issue Dec 4, 2019 · 4 comments
Open

Cant parse a simple date #100

rmasci opened this issue Dec 4, 2019 · 4 comments

Comments

@rmasci
Copy link

rmasci commented Dec 4, 2019

] $ dateparse --timezone="America/Denver" "Dec 4 10:19"
fatal: parsing time "Dec 4 10:19" as "Jan 2 10:19": cannot parse ":19" as "0:"

Thanks, but I'll look for another utility to do this.

@uditrana
Copy link

Did you find another option?

@araddon
Copy link
Owner

araddon commented Oct 1, 2020

thank you for report. Im not sure I am ready to write a fix to that, it entails assuming the missing year is the current year. That sounds like an innocuous assumption but one I feel is just too large of an assumption? If the format you have is stable, then i would use the time.Parse() with your own layout. This lib attempts to allow for different semi-standardish layouts, but without making too many assumptions. open for other comments.

@uditrana
Copy link

uditrana commented Oct 1, 2020

I think there are sufficient use cases where you want to parse dates relative to each other in the context of the date information that is provided. In that, if there is no year provided, being able to parse it successfully with any assumed year is useful so that those dates can still be used. Time.Parse() does this as well by assuming a zero year for information that lacks that information.

Might be worth offering a flag that will assume some information if not present.

@lezhnev74
Copy link

I just stumbled upon this failure: 1 April 2022 23:59 is not recognizable, while 1 Apr 2022 23:59 is fine. I think recognition of so many templates is a hell of a task, no wonder we see strange things like that.

klondikedragon added a commit to itlightning/dateparse that referenced this issue Dec 12, 2023
* Don't just assume we were given one of the valid formats.
* Also consolidate the parsing states that occur after timePeriod.
* Add subtests to make it easier to see what fails.
* Additional tests for 4-char timezone names.
* Fix araddon#117
* Fix araddon#150
* Fix araddon#157
* Fix araddon#145
* Fix araddon#108
* Fix araddon#137
* Fix araddon#130
* Fix araddon#123
* Fix araddon#109
* Fix araddon#98
* Addresses bug in araddon#100 (comment)

Adds test cases to verify the following are already fixed:
* araddon#94
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

4 participants