JoaoJandre opened a new pull request, #7032: URL: https://github.com/apache/cloudstack/pull/7032
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) - [X] Bug fix (non-breaking change which fixes an issue) - [X] 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 - [X] Minor #### Bug Severity - [ ] BLOCKER - [ ] Critical - [ ] Major - [X] 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 | the events were properly listed | -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
