Aaron Raddon

ok, thx for the report alex . I see the issue which is the dd/mm/yyyy format which is ambiguous to this type of parsing compared to mm/dd/yyyy . I think...

Fairly certain this is actually the same issue as #28

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...

I wrote this, which seems to have a different Expected output, trying to understand the difference between your expected and what golang seems to output, any thoughts? https://play.golang.org/p/VA5IDWKOcJA ```go package...

Alittle more built out: https://play.golang.org/p/3b3l8BS81rD ``` time.ParseInLocation() : 2017-12-31 16:00:00 +0800 AWST time.ParseInLocation() : t.In(perth) => 2017-12-31 16:00:00 +0800 AWST time.Parse() (w time.Local=Australia/Perth) : 2017-12-31 16:00:00 +0000 UTC time.Parse() (w...

This sounds like possibly a question for the Elasticsearch Client? The `date` returned from dateparse.ParseIn() is a normal `time.Time` and the elasticsearch range query would be a question of 1)...

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...

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

Do you mind clarifying for me is the "2015-06-10" `October 6th 2015` or is that `June 10th 2015`, just to be absolutely sure.

Hm, seems go doesn't really like that offset format (seems to not support the combo of GMT[+-]hh:mm ie with the colon?) https://play.golang.org/p/fjk2fFKNAwu ```go package main import ( "fmt" "time" )...