incorrect time span for accumulatedCost report last 7 days cost includes 8 days in range

[joekru]

totals, lastSevenDaysCost includes an 8 day period - the previous 7 days plus today. So for example it is returning Tuesday April 2 to Tuesday April 9, inclusive.

[joekru]

Also note that the time period covered seems to be bounded by the 1st of each month rather than be a rolling 7 days cost. For example, on May 6 the time period will only be from May 1 to May 6. It shows the same as month-to-date before the 8th of each month.

[Daniel-Spindler-Mandalay]

Regarding the time period covered:
By default, when a timeframe is not specified, it defaults to: BillingMonthToDate
https://github.com/mivano/azure-cost-cli?tab=readme-ov-file#timeframe
This means it pulls all data for the current month starting at the first of the current month. It won't have data available for any period from the previous month - hence only shows from the 1st of the current month. Using a custom timeframe can get around this.
Example: -t Custom --from 2024-03-01 --to 2024-04-30

As for the main issue, I wonder if this could be something to do with time zone differences as the code date assessment uses UtcNow in combo with DateOnly.
What time zone are you in? What time of day do you run the command? As its using UTC would expect different results on either side of a UTC date change when converted to your time zone.
Also be a good idea to confirm the version of Azure Cost Cli you are using. Best to be on latest.

lastSevenDaysCost = accumulatedCostDetails.Costs.Where(a => a.Date >= DateOnly.FromDateTime(DateTime.UtcNow.AddDays(-7)))

[joekru]

It does seem the labels for the values can be misleading depending on whether a custom timeframe is used or not. For example, when specifying a timeframe of a 7 day period there is still a value for 'lastThirtyDaysCost'. Of course, it is the same as 'lastSevenDaysCost' in that instance. Thanks for clarifying the behavior - I'll just need to run the script 2 times: once to get month to date and once to get rolling 30- and 7-day stats.

I am in US Central time zone and generally running the command in the AM. My version (today) is 0.39.0+526ada73468d88e535e0f8e4f84b21405b3be4fb. The script I wrote as a wrapper updates azure-cost each time before running the command.

[DanielSpindler83]

If you are in Central time as UTC -5, then the only period that your date (day of the month) is behind UTC is from midnight to 5am UTC time (7pm to midnight Central time). I think. I am terrible with times and dates.
So if you run it in the am in your time zone the date should always be the same as UTC date.

I am in Australia UTC + 10 and have this sort of thing often with different things, UTC date changes at 10am for us and we are ahead in date for 10 hours each morning.

It does raise an interesting discussion around weather the app needs to be time zone aware when doing periods like this, but the data that comes back from Microsoft is in UTC, I think. So may make sense to do it the way it is doing it, but maybe in a more explicit way that makes it obvious.