Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
joekru opened this issue Apr 9, 2024 · 5 comments

Comments

@joekru
Copy link

joekru commented Apr 9, 2024

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.

image

@joekru
Copy link
Author

joekru commented May 6, 2024

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
Copy link

Daniel-Spindler-Mandalay commented May 21, 2024

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
Copy link
Author

joekru commented May 21, 2024

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
Copy link
Contributor

DanielSpindler83 commented May 22, 2024

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.

Copy link

stale bot commented Aug 20, 2024

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

@stale stale bot added the wontfix This will not be worked on label Aug 20, 2024
@mivano mivano removed the wontfix This will not be worked on label Aug 20, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants