You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Although ACS stores all dates in the DB with the UTC timezone, all APIs that have parameters of type date are handled according to the server's timezone. In this case, if the server's timezone is in UTC-3, for instance, and user is in UTC-2 and inform yyyy-MM-dd 09:00:00 in the parameter, the Date object will be yyyy-MM-dd 09:00:00 (UTC-3) and ACS will convert it to yyyy-MM-dd 12:00:00 while querying the database. This way, if the final users want to retrieve data from date 09:00:00, they must know the server's timezone in order to inform the correspondent date (in this example, yyyy-MM-dd 06:00:00).
This situation is very clear when calling the listvirtualmachinesusagehistory API. If the data was collected at yyyy-MM-dd 12:00:00 (UTC), final user must know that the server is in UTC-3 and inform yyyy-MM-dd 09:00:00. Via UI, either using the local timezone or not, the informed timestamp is always converted to UTC. Then, the server would consider this converted timestamp as UTC-3, and would convert it to UTC again, adding 3 hours to the date and returning nothing. Example: user is in UTC-2 and informs yyyy-MM-dd 10:00:00; the UI converts it to UTC (yyyy-MM-dd 12:00:00); ACS interprets it as UTC-3 and converts again to UTC (yyyy-MM-dd 15:00:00).
To handle this situation, an extension was made to allow all APIs that have parameters of type date to also receive them in the format with timezone yyyy-MM-dd'T'HH:mm:ssZ, for example, 2022-12-20T14:33:42+0100. This change only extends the date parameter, previous behavior still works normally. Thus the user will be able to send requests with the chosen timezone, and the ACS will carry out the conversion to the timezone it operates.
Furthermore, the VM stats listing in the UI has been updated to always send the date and time with the timezone of the user's machine.
Types of changes
Breaking change (fix or feature that would cause existing functionality to change)
New feature (non-breaking change which adds functionality)
Bug fix (non-breaking change which fixes an issue)
Enhancement (improves an existing feature and functionality)
Cleanup (Code refactoring and cleanup, that may add test cases)
Feature/Enhancement Scale or Bug Severity
Feature/Enhancement Scale
Major
Minor
Bug Severity
BLOCKER
Critical
Major
Minor
Trivial
Screenshots (if appropriate):
How Has This Been Tested?
After setting the management server's timezone to UTC+1, and setting vm.stats.max.retention.time to 5, I did the following tests:
#
Test
Result
1
I called the listvirtualmachinesusagehistory API with the startdate as 5 minutes prior to the tests time, passing my timezone (UTC-3)
The stats were correctly recovered
2
I called the API with the same timestamp, but informing UTC-4 as the timezone
No records were returned
3
I called the API with the startdate as 5 minutes prior to the tests time, informing the date and time using the UTC+1 timezone, but without informing the timezone, e.g. 2022-12-28 15:10:00
The stats were correctly recovered
4
I called the API with the startdate as 5 minutes prior to the tests time, informing the date and time using the UTC-3 timezone, but without informing the timezone
No stats were recovered
5
I called the listEvents API with the startDate in the YYYY-MM-DD HH:mm:ss format
@DaanHoogland a Jenkins job has been kicked to build packages. It will be bundled with KVM, XenServer and VMware SystemVM templates. I'll keep you posted as I make progress.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Although ACS stores all dates in the DB with the UTC timezone, all APIs that have parameters of type date are handled according to the server's timezone. In this case, if the server's timezone is in UTC-3, for instance, and user is in UTC-2 and inform
yyyy-MM-dd 09:00:00in the parameter, the Date object will beyyyy-MM-dd 09:00:00(UTC-3) and ACS will convert it toyyyy-MM-dd 12:00:00while querying the database. This way, if the final users want to retrieve data from date09:00:00, they must know the server's timezone in order to inform the correspondent date (in this example,yyyy-MM-dd 06:00:00).This situation is very clear when calling the
listvirtualmachinesusagehistoryAPI. If the data was collected atyyyy-MM-dd 12:00:00(UTC), final user must know that the server is in UTC-3 and informyyyy-MM-dd 09:00:00. Via UI, either using the local timezone or not, the informed timestamp is always converted to UTC. Then, the server would consider this converted timestamp as UTC-3, and would convert it to UTC again, adding 3 hours to the date and returning nothing. Example: user is in UTC-2 and informsyyyy-MM-dd 10:00:00; the UI converts it to UTC (yyyy-MM-dd 12:00:00); ACS interprets it as UTC-3 and converts again to UTC (yyyy-MM-dd 15:00:00).To handle this situation, an extension was made to allow all APIs that have parameters of type date to also receive them in the format with timezone
yyyy-MM-dd'T'HH:mm:ssZ, for example,2022-12-20T14:33:42+0100. This change only extends the date parameter, previous behavior still works normally. Thus the user will be able to send requests with the chosen timezone, and the ACS will carry out the conversion to the timezone it operates.Furthermore, the VM stats listing in the UI has been updated to always send the date and time with the timezone of the user's machine.
Types of changes
Feature/Enhancement Scale or Bug Severity
Feature/Enhancement Scale
Bug Severity
Screenshots (if appropriate):
How Has This Been Tested?
After setting the management server's timezone to UTC+1, and setting
vm.stats.max.retention.timeto 5, I did the following tests:listvirtualmachinesusagehistoryAPI with thestartdateas 5 minutes prior to the tests time, passing my timezone (UTC-3)startdateas 5 minutes prior to the tests time, informing the date and time using the UTC+1 timezone, but without informing the timezone, e.g.2022-12-28 15:10:00startdateas 5 minutes prior to the tests time, informing the date and time using the UTC-3 timezone, but without informing the timezonestartDatein theYYYY-MM-DD HH:mm:ssformat