Parse dates in current Location?

[Xfennec]

Hi,
First, big thanks for this library, it's awesome, really.

I use custom functions in my expression returning (float64)xxx.Unix() values (I hope it's correct to do so?). But when comparing values with literal dates like '2017-03-11' (without an explicit zone) , I have timezone offset.

Currently, dates are parsed using time.Parse() and the documentation states "In the absence of a time zone indicator, Parse returns a time in UTC." It makes me think that time.ParseInLocation() with the current Location should be used instead.

What do you think? It sounds OK to you? If so, I can create a PR, of course.

Thanks again for the lib !

[Knetic]

Hey, thanks for using the library!

First, yes that's correct to return (float64)xxx.Unix(), the library handles time by converting to the float64 representation of "unix time".

And, yeah, i think you're probably right that ParseInLocation is the right way to do it. I hadn't given it much thought at the time, but I can't think of a reason why it shouldn't use the current location by default. Go ahead and make a PR! 👍

[Xfennec]

Thanks for the answer. While thinking about this, I realize that it could be a good idea to let the user chose its setting about date parsing, that may be time.Local or any particular Location. It also allows the default to be time.UTC so it will (mostly) match the current behavior of the library and won't break compatibility.

If I try to had such thing, how do you see it? As a per-expression setting or a global one? What the API would look like? Any thoughts?

[Knetic]

It could be a good idea to have that kind of setting, but seems sort of edge-case. I wouldn't worry about it for now. If it becomes a problem, there are a couple ways to handle it later.

I'm not so concerned with compatibility, this actually feels like it borders on a bug. If i were a user, i would expect to be able to pass time.Now() as a parameter - which returns the current Location's time, which would lead to me comparing a time literal, parsed in UTC (because it uses time.Parse), against a parameter, which is in the current Location.

Parsing in the current location (unless explicitly specified in the time string) is also is what i think most users would expect.