dhis2-devs team mailing list archive

[Olav Poppe <olav.poppe@xxxxxx>]

Still, this means that:
1) «Last quarter» (and to some extent «Last 4 quarters») cannot be used for quarterly routine data, which is probably the second most common period type, since any report would then be empty two thirds of the time.

2) Regarding monthly datasets being aggregated: 
- if what you need is a report for the quarter, which is common a lot of places I think, you will have to wait until the end of the quarter anyway. 
- if you want to get data for the quarter before it is finished, then «last month», «last 3 months» or «last bi-month» are all alternatives. For quarterly data, on the other hand, there are no real alternative except using fixed periods, which is not useful for dashboards or easily reusable favorites.

There are of course cases where you actually want to get a report for «so far this quarter», which is what you get currently, but I find it hard to believe that it is the most common use case, and that the benefits of having that outweigh all the downsides. And with anything tracker-related, the assumption about data being monthly does not make sense.

If all period types had both «last» and «current» as options, and they actually gave you the last and current periods, I think it would make things a lot easier.



> 9. jan. 2015 kl. 12.23 skrev Lars Helge Øverland <larshelge@xxxxxxxxx>:
> 
> Sorry I got it a bit wrong.
> 
> All relative periods (except weekly) "switch over" one month after the start date of the relative period, not the end.
> 
> The reasoning is the same. Often data is entered monthly. If you create e.g. a chart with "this quarter", which aggregates the monthly data into a quarter", the system waits a month until you have at least some data in the system before switching the quarter for the chart.
> 
>