Support month unit and proper years in duration

[chrismo]

Primitive Values in the 1.18 docs show that "month" is not included unit in the type:

Valid time units are "ns" (nanosecond), "us" (microsecond), "ms" (millisecond), "s" (second), "m" (minute), "h" (hour), "d" (day), "w" (7 days), and "y" (365 days). Note that each of these time units accurately represents its calendar value, except for the "y" unit, which does not reflect leap years and so forth. Instead, "y" is defined as the number of nanoseconds in 365 days.

I presume this is because dealing with the varying lengths of months is some work, same as dealing with leap years. I have a use-case working moving dates where having month support would be handy. Instead, I'll drop back to the shell and use GNU date for what I need.

[philrz]

@chrismo: Indeed, it seems to be one of those problems with no single pure solution, so users are stuck figuring out what compromises they're willing to make and settling for a "good enough" approach that suits their needs. Debates on this topic can be found attached to many of the "duration" libraries for various programming languages, and this StackOverflow post seems to do a decent job of walking through much of the topic.

If we can add enhancements that help get closer to "good enough", I expect use case details from users like you or anyone else watching this issue would help a lot.

Just doing some general riffing along the lines of how I see other folks coping, some just take the simplistic approach just using an approximate month measured in days, e.g., if trying to find approximately "one month" out from a given timestamp:

$ echo '2018-03-24T17:15:21.411148Z' | zq -z 'this + 30d' -
2018-04-23T17:15:21.411148Z

Or if you want to be more accurate, maybe use a helper constant:

$ echo '2018-03-24T17:15:21.411148Z' | zq -z 'const MonthIsh = 365.25d / 12 this + MonthIsh' -
2018-04-24T03:45:21.411148Z

And I feel like I should point out that for working with calendar months, the strftime function might come in handy. So for instance if you were trying to do aggregations "by month", you might start from the bucket function and get stuck because its duration-type argument span can't take a month-based parameter. But you can make a string-based year+month calendar bucketing with strftime, such as if I wanted to count the timestamps in the attached times.zng.gz by calendar month.

$ zq -z 'head 3' times.zng.gz
{ts:2015-04-13T09:34:44.73264Z}
{ts:2015-04-13T09:34:44.727039Z}
{ts:2015-04-13T09:34:44.727022Z}

$ zq -z 'YearMonth:=strftime("%Y-%m", ts) | count() by YearMonth' times.zng.gz
{YearMonth:"2015-04",count:169479(uint64)}
{YearMonth:"2015-03",count:326269(uint64)}
...

But these are just food for thought absent specific use cases. Folks watching this issue should please speak up with their details. Thanks!

[chrismo]

My use case is working with data like a recurring monthly activity, and I wanted to be able to move a due date forward one month and have it "just work" so that Aug 31st could be moved forward to Sep 30 (last day of the month). The case of going from Sep 30 to Oct 30 vs Oct 31 (last day of month) - there's no way I can think to have a reasonable default other than Oct 30 with just simple duration addition ... but, that would be fine with me if I could do + 1mo or somesuch.

I also know how complicated this stuff can get, and y'all may decide it's out of scope for zed, which would be understandable to me.