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

Request: Support for DD/MM/YYYY #28

Open
matthewhartstonge opened this issue Aug 29, 2017 · 7 comments · May be fixed by #88
Open

Request: Support for DD/MM/YYYY #28

matthewhartstonge opened this issue Aug 29, 2017 · 7 comments · May be fixed by #88

Comments

@matthewhartstonge
Copy link

matthewhartstonge commented Aug 29, 2017

Hello!

I noticed dateparse doesn't currently have support for UK based dates, is this within scope?

Flipped examples from mm/dd/yyyy:

	// dd/mm/yyyy
	"31/3/2014",
	"31/03/2014",
	"21/08/71",
	"1/8/71",
	"8/4/2014 22:05",
	"08/04/2014 22:05",
	"2/04/2014 03:00:51",
	"8/8/1965 12:00:00 AM",
	"8/8/1965 01:00:01 PM",
	"8/8/1965 01:00 PM",
	"8/8/1965 1:00 PM",
	"8/8/1965 12:00 AM",
	"4/02/2014 03:00:51",
	"19/03/2012 10:11:59",
	"19/03/2012 10:11:59.3186369",
@araddon
Copy link
Owner

araddon commented Aug 29, 2017

Let me play around and see what that would look like. Since dd/mm vs mm/dd are ambiguous for this state-machine, I think it would have to be declarative (different function name).

@araddon
Copy link
Owner

araddon commented Mar 15, 2018

Still working on this. Have finished refactor as precursor and will create an API to prefer DD/MM when ambigous.

@stevenroose
Copy link

Internationally, dd/mm is way more common than mm/dd, right? Afaik, only the USA uses mm/dd, while the entire rest of the world uses mm/dd..

@alecthomas
Copy link

According to WP, DMY is by far the most used format, then YMD, distantly followed by the remainder including MDY.

What about using the system timezone to set a default format?

araddon pushed a commit that referenced this issue Mar 25, 2018
araddon added a commit that referenced this issue Mar 25, 2018
@sworisbreathing
Copy link

The current implementation of ParseStrict might be a bit more strict than it really needs to be. For date strings such as 13/08/2018, you can rule out any ambiguity because a) you have a 4-digit year, so you know which is the year part, and b) you know there's no month value greater than 12.

@kkesley
Copy link

kkesley commented Nov 2, 2018

I'm currently stuck on this one too.. What about exposing the preferMonthFirst setting?

@KamalGalrani KamalGalrani linked a pull request Jul 9, 2019 that will close this issue
mehanizm added a commit to mehanizm/dateparse that referenced this issue Aug 9, 2021
@mehanizm
Copy link

mehanizm commented Aug 9, 2021

Hi, @matthewhartstonge

All the cases where the dd and mm is ambiguous are working correctly in my fix
#133

You can use my fork while it is waiting for a merge
go get github.com/mehanizm/dateparse@ea6d70072703

klondikedragon added a commit to itlightning/dateparse that referenced this issue Dec 13, 2023
Test cases now validates the following is true:
* Fixed araddon#91
* Fixed araddon#28

(previous commits already addresses these issues, these tests ensure
that these issues remain fixed)
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

Successfully merging a pull request may close this issue.

7 participants