[feature request] Support month and year as duration unit

[ghost]

For example:

• 1M for 1 month
• 1y for 1 year

Its useful for me when i want to query the data last month and year...

[otoolep]

@diiidiii -- how long is a month?

[beckettsean]

@diiidiii the challenge with supporting month or year durations is that they are not regular. It requires InfluxDB to be aware of things like variable month lengths, leap years, etc. This is a potential feature but certainly not a short-term one.

[ghost]

they are not regular

Yes thats the reason why i need it. I know it isn't easy to implement but i just want to notify you that this will maybe a good feature. At the moment i use 30d, itsnt not always correct but its okay

[daviesalex]

Anybody that comes across this because Grafana is sending queries that have ''1y'' in them, see https://github.com/grafana/grafana/issues/2874

The workaround to that bug is to set a minimum span on the grafana pane.

[dstreppa]

+1

[jaapz]

Would be great to have this. It's not a trivial problem, but then again, InfluxDB is a time-series database, so it should have a good notion of what certain time durations are, right?

[gsemet]

Agree, I would like to be able to group by month or year and have grafana at least handle all subtilities automatically

[stantonk]

👍

[ryanmills]

+1 need ability to group by time(1M) (month) or time(1y) (year)

[Wolfgang1966]

I would also like to have the ability to group by month and year.

Thanks a lot

Wolfgang

[Wolfgang1966]

@beckettsean By the way, days are not regular also ... thinking of DST switches, leap seconds a.s.o. :)

[tyhunt99]

+1 need ability to group by time(1M) (month) or time(1y) (year)

as a time-series database isn't this sort of a standard feature?

[ale91x]

+1 need ability to group by time(1M(month)), (1y(year))

[xsherlockpl]

I cant get solar production for the last month with just one query without that. +1

[olro]

+1 in general it is nice to have e.g. consumption data for water, electricity, gas on a per month/year basis

[m-tymchyk]

+1 need ability to group by time(1M) (month) or time(1y) (year)

[smalenfant]

+1 We derive bandwidth capacity by month, this makes it a little hard. Currently using 4w or 30d. Data not far off, just not exactly what the report viewer expects.

[mkren]

+1

[gtt116]

+1 need ability to group by time(1M) (month) or time(1y) (year)

[lcarsos]

+1 grouping by 30d only gets you so far, and frustrates users when they compare against previous results and numbers for finished months change.

[cicciopizza]

+1 need ability to group by month / year. ex. 1M / 1Y

[mikegroot]

+1

[chfumero]

+1

[zandacw]

+1

[zopyx]

+100

[zopyx]

My workaround for grouping rows by year+month is by adding a tag "ym=YYYY-MM" to each row. Then you can "GROUP BY ym".

[Codelica]

Which is fine if you have relatively low series series cardinality or lots of RAM. But otherwise the 12x annual multiplier is too heavy for measurements like ours. I'm hoping Influx will provide the ability natively, or potentially provide some timestamp functions as a workaround similar to what people do for groupings like this on SQL servers.

[SilentButeo2]

+1 Used influxdb because it was described as a time series database. So grouping /month, /year, was something I thought was implemented by default. My mistake it seems. I know dates can be difficult, but with things like tzdata, you can do great stuff. Keep up the good work guys!

[grydstedt]

+1

[ADahmani]

+1

[Oxydros]

+1

[mythfish]

+1

[MThomassen]

+1

[patrickvallet]

+1, really important for me too.

[lqjing]

+1

[matyunin]

+1

[steveseeger]

+1.. couldn't believe this didn't make 1.0 priority. Even a low performance solution. It requires setting the relative timezone, is that the complexity issue? I assumed this would be here before switching over our platform from MySQL. Have to change to loop and query per month and manually construct results..

[chywwq]

+1

[kevinsteger]

+1 Lack of this feature makes this influx/grafana problematic for any accounting application.

[pgayvallet]

+1. Blocker for our usages.

[SR-G]

Also +1, would definitely be very usefull.

[aguiraf]

+1

[KlonD90]

+1

[g-k-r]

+1 and while you are at it you might want to consider adding Q for quarter, so 'timestamp/Q' translates to time frame of the quarter the timestamp is in. i.e. 2017-10-12/Q -> 2017-10-01 >= t < 2018-01-01] and Group By time (1Q) aggregates by these time frames.

thanks for a great tool

[dietert]

+1

[akarakotov]

+1 grafana+influxdb is the best solution for real-time monitoring and alerting, but we can't right now detect problems within calendar month period because of this feature absense.

[codingheld]

+1 This is a blocker for production use...

[martinschuberts]

+1

[zopyx]

Hard to believe how ignorant and arrogant the Influx-DB team is here on this issue.

[dgomes]

+1