Auto-detect time format in form binding

[alxarch]

By using github.com/araddon/dateparse in binding/form_mapping.go the time_format tag can be optional.

[codecov]

Codecov Report

Merging #1037 into master will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master    #1037   +/-   ##
=======================================
  Coverage   96.66%   96.66%           
=======================================
  Files          16       16           
  Lines        1711     1711           
=======================================
  Hits         1654     1654           
  Misses         49       49           
  Partials        8        8

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 7fafb3f...f4755ac. Read the comment docs.

[appleboy]

Please add testing code.

[alxarch]

There's no tests for form_mapping in general. Are they in a separate dir?

[alxarch]

Ok I added a test to binding_test.go.

[appleboy]

LGTM. @javierprovecho Please help to review.

[andreynering]

👍 for this change.

Do you really need to add another lib for this? We can try try some common formats like this:

var timeFormats = []string{
        "02/01/2006",
        "02/01/2006 15:04",
        "02/01/2006 15:04:05",
        // many other common formats
}

func tryParseTime(str string) (time.Time, error) {
        for _, fmt := range timeFormats {
                if t, err := time.ParseInLocation(fmt, str, time.Local); err == nil {
                        return t, nil
                }
        }
        return time.Time{}, ErrTimeFormatNotReconized
}

[andreynering]

What location does ParseAny assume?

See below that the current behavior is using local timezone by default, unless a utc tag is informed in the field. I think it is desirable to keep this behavior.

[alxarch]

Quoting from the araddon/dateparse module

The location your server is configured effects the results

There exists the dateparse.ParseIn(datestr string, loc *time.Location) (time.Time, error) method. I can switch to this to retain the tag behaviour.

[alxarch]

About the separate lib the only benefit is that it uses a byte reader with state switch to determine the format to be more efficient.

[alxarch]

Changed the behaviour to respect time_utc tags

[firstrow]

less 3rd party deps is better. I think user should be able to choose any datetime parsing lib he wants.

[alxarch]

I don't see a way to add user choosable date parser without resorting to treating date args as strings and parsing dates in the controller. The whole point of binding is to get over with parsing request parameters with just adding a few tags to a struct. As to the separate dependency issue, the lib is quite simple and has it's own tests and documentation. Adding a simple for with predefined formats is a solution that can avoid using a dep but at the same time lays the burden of testing and documenting to the gin codebase. The current behavior is partly undocumented as it requires a time_format tag to function properly and only works for one format (and i don't see a way to add multiple formats because you can't distinguish
easily between a format separator and a time format character).

[javierprovecho]

it's a feature, however i don't like the idea of loading chains of deps in gin, I've changed the milestone for the next version (not 1.4, already due), i'll give it a look later...