Detail:
The ToUint6E4 function in the Go cast library was fixed to correctly handle strings that overflow the maximum value of int64.
Previously, the function incorrectly returned zero for these input values because it was using strconv.ParseInt internally, which doesn't handle values greater than the max int64. The fix replaces the use of strconv.ParseInt with strconv.ParseUint.
The current top 2 formats are, from some checks I've done, 2 dominant formats used in Hugo projects.
Checking these first has a big effect:
```bash
name old time/op new time/op delta
CommonTimeLayouts-10 1.45µs ± 0% 0.33µs ± 1% -77.45% (p=0.029 n=4+4)
name old alloc/op new alloc/op delta
CommonTimeLayouts-10 1.55kB ± 0% 0.18kB ± 0% -88.14% (p=0.029 n=4+4)
name old allocs/op new allocs/op delta
CommonTimeLayouts-10 38.0 ± 0% 6.0 ± 0% -84.21% (p=0.029 n=4+4)
```
See https://github.com/gohugoio/hugo/issues/10942
* Allow strings/json.Number with just zeroes after the decmial point to be converted to integer`
* Allow nil in ToFloat*
* Remove some test duplication
* replace testify with quicktest
* Enable integer and float conversion of time.Weekday values
Fixes#139Fixes#141
Go's time parsing uses UTC when the format doesn't have a tiemzone, and
has even weirder behavior when it has a zone name but no numeric offset.
A caller to `cast.ToTime` won't know if the returned time was explicitly
in UTC, or defaulted there, so the caller cannot fix it. These new
functions allow a user to supply a different timezone to default to,
with nil using the local zone.
Adds a form to handle the common format `strftime("%FT%T%z")`, which
omits the (optional) colon from the timezone. Also adds a matching
T-omitted form.
It used to return zero valeus in some cases. The details are described
in [this issue](https://github.com/spf13/viper/issues/203). More cases
were also added in the unit test `TestToDuration()`