@TrystanLea - this should have had more discussion.
@stuart, the current view
which I agree is not enough, but your proposal is just too verbose - as you point out Mobile does not work and plenty of folk use it on a tablet!
What problem are you solving? Matching the output to billing periods? Will 30d make any real difference over M? What if your billing period starts mid month?
The original proposal was to add 24h (12h make no sense to me) as the previous 24h and day is since midnight (TZ adjusted or UTC?).
The extra ‘days’ setting, doesn’t really make any difference over week, month etc unless this means week to date rather than 7d (which then needs some explanation).
To be consistent you need a 2 Month entry as well.
To me these additional periods are just noise and in any case it needs to be more concise.
I’d suggest ** 24h, D, D-1, 7D, 30D, 60D **
I’d suggest ** 24h, D, D-1, M, M-1, 7D, 30D, 60D **
I’d suggest ** 24h, d, 7d, 30d, 60d, D-1, M, M-1**
- 24 Hr period
- Day since midnight (TZ adjusted or UTC?)
- previous 7 days use from now (i.e. 7*24H)
- previous 30 days use from now (i.e. 30*24H)
- previous 60 days use from now (i.e. 60*24H)
- Yesterday midnight to midnight (TZ adjusted or UTC?)
- Current month midnight on 1st to now (TZ adjusted or UTC?)
- Last month midnight first day to 23:59 last day (TZ adjusted or UTC?)
 - added in month options
[edit2] - d = since mignight, D = midnight-midnight. Changed grouping.