Normalize dates in Usage and Quota APIs #8243
Merged
Conversation
This file contains 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
|
Here is the full response of the Response |
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #8243 +/- ##
=========================================
Coverage 31.11% 31.12%
- Complexity 33926 33933 +7
=========================================
Files 5398 5398
Lines 379564 379509 -55
Branches 55380 55373 -7
=========================================
+ Hits 118109 118110 +1
+ Misses 245765 245745 -20
+ Partials 15690 15654 -36
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. |
There was a problem hiding this comment.
I'm not so sure we should abandon private Date computeAdjustedTime(Date initialDate, TimeZone targetTZ), this will have to be tested in strange scenarios. I've seen Cloudstack installations have trouble with a MS in Singapore and a DC in Australia. These kinds of situations can actually occur within a country easily.
@DaanHoogland the use of the |
@winterhazel @GutoVeronezi , I would like to see extensive testing on this, but your explanation makes sense. |
Co-authored-by: dahn <[email protected]>
|
Hey @DaanHoogland, I tried to replicate the scenario you described here, with a MS in Singapore (MS and Some problems I have identified which this PR fixes: Unable to add credits with quotaCreditsBefore the changes: The time in Singapore was (admin) 🐱 > quota credits account=admin domainid=72b54c4a-771d-11ee-8e59-5254003754dc value=5
🙈 Error: (HTTP 431, error code 4350) Incorrect deposit date: Mon Jan 22 21:22:55 SGT 2024 there are balance entries after this dateBut the MS would not let me add credits to any account, since it incorrectly calculated the current date (deposit date) as being 3 hours before the actual date, and therefore detected balance entries after it. After: The time in Singapore was (admin) 🐱 > quota credits account=admin domainid=72b54c4a-771d-11ee-8e59-5254003754dc value=5
{
"quotacredits": {
"credits": 5,
"currency": "$",
"updated_by": "admin",
"updated_on": "2024-01-19T21:26:06+0800"
}
}And was able to successfully add credits to the account.
(admin) 🐱 > quota balance account=admin domainid=72b54c4a-771d-11ee-8e59-5254003754dc startdate=2024-01-18 enddate=2024-01-19
{
"balance": {
"credits": [
{
"credits": 5,
"updated_on": "2024-01-19T21:26:06+0800"
}
],
"currency": "$",
"enddate": "2024-01-19T23:59:59+0800",
"endquota": 5,
"startdate": "2024-01-18T00:00:00+0800",
"startquota": 0
}
}listUsageRecords does not retrieve the requested dataBefore the changes: The current time in Australia was (admin) 🐱 > list usagerecords startdate='2024-01-22T19:00:00+1100' enddate='2024-01-23T04:00:00+1100'2024-01-23 00:11:26,343 DEBUG [c.c.u.UsageServiceImpl] (qtp391630194-23:ctx-acf58df9 ctx-d3f654e9) (logid:ba781cb9) getting usage records for account: 2, domainId: null, between Mon Jan 22 13:00:00 SGT 2024 and Mon Jan 22 22:00:00 SGT 2024, using pageSize: 500 and startIndex: 0MS queries for usage records between After the changes: The current time in Australia was (admin) 🐱 > list usagerecords startdate='2024-01-22T19:00:00+1100' enddate='2024-01-23T07:59:00+1100'2024-01-23 02:10:21,078 DEBUG [c.c.u.UsageServiceImpl] (qtp391630194-19:ctx-9e97b4a7 ctx-395a7f59) (logid:38101bda) Getting usage records for account [2] in domain [null], between [Mon Jan 22 16:00:00 SGT 2024] and [Tue Jan 23 04:59:00 SGT 2024], using pageSize [500] and startIndex [0].MS queries for usage records between Wrong dates in quotaTariffCreateBefore: (admin) 🐱 > quota tariffcreate name="testA" value=2 usagetype=1 startdate="2024-01-24T01:00:00+1100"
{
"quotatariff": {
"currency": "$",
"effectiveDate": "2024-01-23T19:00:00+0800",
"name": "testA",
"tariffValue": 2,
"usageDiscriminator": "None",
"usageName": "RUNNING_VM",
"usageType": 1,
"usageTypeDescription": "Running Vm Usage",
"usageUnit": "Compute*Month",
"uuid": "b3074921-fd3d-46bd-a5e6-19c445c9a7d8"
}
}When creating a Quota tariff, (admin) 🐱 > quota tariffcreate name="test2A" value=2 usagetype=1 startdate="2024-01-25T01:00:00+1100" enddate="2024-01-25T04:00:00+1100"
{
"quotatariff": {
"currency": "$",
"effectiveDate": "2024-01-24T19:00:00+0800",
"endDate": "2024-01-24T22:00:00+0800",
"name": "test2A",
"tariffValue": 2,
"usageDiscriminator": "None",
"usageName": "RUNNING_VM",
"usageType": 1,
"usageTypeDescription": "Running Vm Usage",
"usageUnit": "Compute*Month",
"uuid": "c22ac24b-45ea-4ba2-8dc2-533592ac46ca"
}
}Both Just to ensure that this is not a problem only with the API's response, I verified that they are indeed wrong in the database: +----+------------------------+---------------------+---------------------+
| id | name | effective_on | end_date |
+----+------------------------+---------------------+---------------------+
| 26 | testA | 2024-01-23 11:00:00 | NULL |
| 27 | test2A | 2024-01-24 11:00:00 | 2024-01-24 14:00:00 |
+----+------------------------+---------------------+---------------------+After: (admin) 🐱 > quota tariffcreate name="testB" value=2 usagetype=1 startdate="2024-01-24T01:00:00+1100"
{
"quotatariff": {
"currency": "$",
"effectiveDate": "2024-01-23T22:00:00+0800",
"id": "201b2163-8194-48ff-a048-c36453677538",
"name": "testB",
"tariffValue": 2,
"usageDiscriminator": "None",
"usageName": "RUNNING_VM",
"usageType": 1,
"usageTypeDescription": "Running Vm Usage",
"usageUnit": "Compute*Month"
}
}
(admin) 🐱 > quota tariffcreate name="test2B" value=2 usagetype=1 startdate="2024-01-25T01:00:00+1100" enddate="2024-01-25T04:00:00+1100"
{
"quotatariff": {
"currency": "$",
"effectiveDate": "2024-01-24T22:00:00+0800",
"endDate": "2024-01-25T01:00:00+0800",
"id": "6f7f9250-425b-493d-8cc0-7b5158d73ea4",
"name": "test2B",
"tariffValue": 2,
"usageDiscriminator": "None",
"usageName": "RUNNING_VM",
"usageType": 1,
"usageTypeDescription": "Running Vm Usage",
"usageUnit": "Compute*Month"
}
}Both In the database: +----+------------------------+---------------------+---------------------+
| id | name | effective_on | end_date |
+----+------------------------+---------------------+---------------------+
| 30 | testB | 2024-01-23 14:00:00 | NULL |
| 31 | test2B | 2024-01-24 14:00:00 | 2024-01-24 17:00:00 |
+----+------------------------+---------------------+---------------------+I also verified that this issue was present in quotaTariffUpdate, and that it has been fixed. Other tests: listUsageRecords(admin) 🐱 > list usagerecords startdate='2024-01-22 19:00:00' enddate='2024-01-23 07:59:00'
...2024-01-24 00:07:06,185 DEBUG [c.c.u.UsageServiceImpl] (qtp391630194-15:ctx-49d437aa ctx-40c137c4) (logid:a6160874) Getting usage records for account [2] in domain [null], between [Mon Jan 22 19:00:00 SGT 2024] and [Tue Jan 23 07:59:00 SGT 2024], using pageSize [500] and startIndex [0].When not adding a timezone, quotaStatement(admin) 🐱 > quota statement account=admin domainid=72b54c4a-771d-11ee-8e59-5254003754dc startdate=2024-01-19T13:00:00+1100 enddate=2024-01-20
{
"statement": {
"currency": "$",
"enddate": "2024-01-20T23:59:59+0800",
"quotausage": [
{
"accountid": 2,
"domain": 1,
"name": "RUNNING_VM",
"quota": 0,
"type": 1,
"unit": "Compute*Month"
},
{
"accountid": 2,
"domain": 1,
"name": "ALLOCATED_VM",
"quota": 0,
"type": 2,
"unit": "Compute*Month"
},
{
"accountid": 2,
"domain": 1,
"name": "IP_ADDRESS",
"quota": 0,
"type": 3,
"unit": "IP*Month"
},
{
"accountid": 2,
"domain": 1,
"name": "NETWORK_BYTES_SENT",
"quota": 0,
"type": 4,
"unit": "GB"
},
{
"accountid": 2,
"domain": 1,
"name": "NETWORK_BYTES_RECEIVED",
"quota": 0,
"type": 5,
"unit": "GB"
},
{
"accountid": 2,
"domain": 1,
"name": "VOLUME",
"quota": 0,
"type": 6,
"unit": "GB*Month"
},
{
"accountid": 2,
"domain": 1,
"name": "TEMPLATE",
"quota": 0,
"type": 7,
"unit": "GB*Month"
},
{
"accountid": 2,
"domain": 1,
"name": "ISO",
"quota": 0,
"type": 8,
"unit": "GB*Month"
},
{
"accountid": 2,
"domain": 1,
"name": "SNAPSHOT",
"quota": 0,
"type": 9,
"unit": "GB*Month"
},
{
"accountid": 2,
"domain": 1,
"name": "SECURITY_GROUP",
"quota": 0,
"type": 10,
"unit": "Policy*Month"
},
{
"accountid": 2,
"domain": 1,
"name": "LOAD_BALANCER_POLICY",
"quota": 0,
"type": 11,
"unit": "Policy*Month"
},
{
"accountid": 2,
"domain": 1,
"name": "PORT_FORWARDING_RULE",
"quota": 0,
"type": 12,
"unit": "Policy*Month"
},
{
"accountid": 2,
"domain": 1,
"name": "NETWORK_OFFERING",
"quota": 0,
"type": 13,
"unit": "Policy*Month"
},
{
"accountid": 2,
"domain": 1,
"name": "VPN_USERS",
"quota": 0,
"type": 14,
"unit": "Policy*Month"
},
{
"accountid": 2,
"domain": 1,
"name": "VM_DISK_IO_READ",
"quota": 0,
"type": 21,
"unit": "IOPS"
},
{
"accountid": 2,
"domain": 1,
"name": "VM_DISK_IO_WRITE",
"quota": 0,
"type": 22,
"unit": "IOPS"
},
{
"accountid": 2,
"domain": 1,
"name": "VM_DISK_BYTES_READ",
"quota": 0,
"type": 23,
"unit": "Bytes"
},
{
"accountid": 2,
"domain": 1,
"name": "VM_DISK_BYTES_WRITE",
"quota": 0,
"type": 24,
"unit": "Bytes"
},
{
"accountid": 2,
"domain": 1,
"name": "VM_SNAPSHOT",
"quota": 0,
"type": 25,
"unit": "GB*Month"
},
{
"accountid": 2,
"domain": 1,
"name": "VOLUME_SECONDARY",
"quota": 0,
"type": 26,
"unit": "GB*Month"
},
{
"accountid": 2,
"domain": 1,
"name": "VM_SNAPSHOT_ON_PRIMARY",
"quota": 0,
"type": 27,
"unit": "GB*Month"
},
{
"accountid": 2,
"domain": 1,
"name": "BACKUP",
"quota": 0,
"type": 28,
"unit": "GB*Month"
}
],
"startdate": "2024-01-19T10:00:00+0800",
"totalquota": 0
}
}
quotaTariffCreate(admin) 🐱 > quota tariffcreate name="testtimezonenotprovided" value=2 usagetype=1 startdate="2024-01-24 10:00:00" enddate="2024-01-25 12:00:00"
{
"quotatariff": {
"currency": "$",
"effectiveDate": "2024-01-24T10:00:00+0800",
"endDate": "2024-01-25T12:00:00+0800",
"id": "ef836a1d-958a-4113-a9da-3121986628a4",
"name": "testtimezonenotprovided",
"tariffValue": 2,
"usageDiscriminator": "None",
"usageName": "RUNNING_VM",
"usageType": 1,
"usageTypeDescription": "Running Vm Usage",
"usageUnit": "Compute*Month"
}
}The tariff is created with the provided dates in the MS's timezone. quotaTariffUpdate(admin) 🐱 > quota tariffupdate name=testB enddate=2024-01-26
{
"quotatariff": {
"currency": "$",
"effectiveDate": "2024-01-23T22:00:00+0800",
"endDate": "2024-01-26T23:59:59+0800",
"id": "7fc5f42a-bc0e-4848-89d7-35eacc64504d",
"name": "testB",
"tariffValue": 2,
"usageDiscriminator": "None",
"usageName": "RUNNING_VM",
"usageType": 1,
"usageTypeDescription": "Running Vm Usage",
"usageUnit": "Compute*Month"
}
}
(admin) 🐱 > quota tariffupdate name=testB enddate=2024-01-26T23:59:59+1100
{
"quotatariff": {
"currency": "$",
"effectiveDate": "2024-01-23T22:00:00+0800",
"endDate": "2024-01-26T20:59:59+0800",
"id": "a2e323b7-10b5-4018-aa9d-e50bbee079ff",
"name": "testB",
"tariffValue": 2,
"usageDiscriminator": "None",
"usageName": "RUNNING_VM",
"usageType": 1,
"usageTypeDescription": "Running Vm Usage",
"usageUnit": "Compute*Month"
}
}Dates are updated according to the provided values. quotaTariffList(admin) 🐱 > quota tarifflist startdate=2024-01-25 enddate=2024-01-26
{
"count": 1,
"quotatariff": [
{
"currency": "$",
"effectiveDate": "2024-01-25T00:00:00+0800",
"endDate": "2024-01-25T23:59:59+0800",
"id": "473451f8-b895-49d5-801c-c4eeea242ec0",
"name": "test3B",
"tariffValue": 2,
"usageDiscriminator": "None",
"usageName": "RUNNING_VM",
"usageType": 1,
"usageTypeDescription": "Running Vm Usage",
"usageUnit": "Compute*Month"
}
]
}
(admin) 🐱 > quota tarifflist startdate=2024-01-25 enddate=2024-01-25T23:59:59+0800
{
"count": 1,
"quotatariff": [
{
"currency": "$",
"effectiveDate": "2024-01-25T00:00:00+0800",
"endDate": "2024-01-25T23:59:59+0800",
"id": "473451f8-b895-49d5-801c-c4eeea242ec0",
"name": "test3B",
"tariffValue": 2,
"usageDiscriminator": "None",
"usageName": "RUNNING_VM",
"usageType": 1,
"usageTypeDescription": "Running Vm Usage",
"usageUnit": "Compute*Month"
}
]
}
(admin) 🐱 > quota tarifflist startdate=2024-01-25 enddate=2024-01-25T23:59:58+0800
<nothing>
(admin) 🐱 > quota tarifflist startdate=2024-01-24T01:00:00+1100 enddate=2024-01-26
{
"count": 3,
"quotatariff": [
{
"currency": "$",
"effectiveDate": "2024-01-25T00:00:00+0800",
"endDate": "2024-01-25T23:59:59+0800",
"id": "473451f8-b895-49d5-801c-c4eeea242ec0",
"name": "test3B",
"tariffValue": 2,
"usageDiscriminator": "None",
"usageName": "RUNNING_VM",
"usageType": 1,
"usageTypeDescription": "Running Vm Usage",
"usageUnit": "Compute*Month"
},
{
"currency": "$",
"effectiveDate": "2024-01-24T22:00:00+0800",
"endDate": "2024-01-25T01:00:00+0800",
"id": "6f7f9250-425b-493d-8cc0-7b5158d73ea4",
"name": "test2B",
"tariffValue": 2,
"usageDiscriminator": "None",
"usageName": "RUNNING_VM",
"usageType": 1,
"usageTypeDescription": "Running Vm Usage",
"usageUnit": "Compute*Month"
},
{
"currency": "$",
"effectiveDate": "2024-01-23T22:00:00+0800",
"endDate": "2024-01-26T23:59:59+0800",
"id": "aa615bcb-a9af-4b2c-8806-6711b8c13623",
"name": "testB",
"tariffValue": 2,
"usageDiscriminator": "None",
"usageName": "RUNNING_VM",
"usageType": 1,
"usageTypeDescription": "Running Vm Usage",
"usageUnit": "Compute*Month"
}
]
}
(admin) 🐱 > quota tarifflist startdate=2024-01-24T02:00:00+1100 enddate=2024-01-26
{
"count": 2,
"quotatariff": [
{
"currency": "$",
"effectiveDate": "2024-01-25T00:00:00+0800",
"endDate": "2024-01-25T23:59:59+0800",
"id": "473451f8-b895-49d5-801c-c4eeea242ec0",
"name": "test3B",
"tariffValue": 2,
"usageDiscriminator": "None",
"usageName": "RUNNING_VM",
"usageType": 1,
"usageTypeDescription": "Running Vm Usage",
"usageUnit": "Compute*Month"
},
{
"currency": "$",
"effectiveDate": "2024-01-24T22:00:00+0800",
"endDate": "2024-01-25T01:00:00+0800",
"id": "6f7f9250-425b-493d-8cc0-7b5158d73ea4",
"name": "test2B",
"tariffValue": 2,
"usageDiscriminator": "None",
"usageName": "RUNNING_VM",
"usageType": 1,
"usageTypeDescription": "Running Vm Usage",
"usageUnit": "Compute*Month"
}
]
}Tariffs are filtered by quotaTariffDelete(admin) 🐱 > quota tariffdelete id=ef836a1d-958a-4113-a9da-3121986628a4
{
"success": true
}Working as expected. Also, could someone else take a look at this PR? @shwstppr @rohityadavcloud |
|
@andrijapanicsb I know you have some experience with this, can you comment on this change? |
GutoVeronezi
approved these changes
Feb 6, 2024
plugins/database/quota/src/main/java/org/apache/cloudstack/api/command/QuotaTariffListCmd.java
Outdated
Show resolved
Hide resolved
plugins/database/quota/src/main/java/org/apache/cloudstack/api/command/QuotaTariffListCmd.java
Show resolved
Hide resolved
...ins/database/quota/src/main/java/org/apache/cloudstack/api/command/QuotaTariffUpdateCmd.java
Show resolved
Hide resolved
DaanHoogland
reviewed
Feb 6, 2024
plugins/database/quota/src/main/java/org/apache/cloudstack/api/command/QuotaTariffListCmd.java
Outdated
Show resolved
Hide resolved
|
This pull request has merge conflicts. Dear author, please fix the conflicts and sync your branch with the base branch. |
|
@blueorangutan package |
|
@DaanHoogland a [SL] 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. |
|
Packaging result [SF]: ✔️ el7 ✔️ el8 ✔️ el9 ✔️ debian ✔️ suse15. SL-JID 8639 |
|
@blueorangutan test |
|
@DaanHoogland a [SL] Trillian-Jenkins test job (centos7 mgmt + kvm-centos7) has been kicked to run smoke tests |
|
[SF] Trillian test result (tid-9192)
|
|
This pull request has merge conflicts. Dear author, please fix the conflicts and sync your branch with the base branch. |
Co-authored-by: Daniel Augusto Veronezi Salvador <[email protected]>
|
@blueorangutan package |
|
@winterhazel a [SL] 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. |
|
Packaging result [SF]: ✔️ el7 ✔️ el8 ✔️ el9 ✔️ debian ✔️ suse15. SL-JID 9197 |
|
The Simulator CI / build is passing; however, Codecov is struggling with something during the report upload; thus the errors in the checks. @DaanHoogland, can we do a last CI run for this one? |
|
@blueorangutan test |
|
@DaanHoogland a [SL] Trillian-Jenkins test job (centos7 mgmt + kvm-centos7) has been kicked to run smoke tests |
|
[SF] Trillian test result (tid-9822)
|
|
@winterhazel I think the smoke test results are environmental, but all but the most trivial GHI tests fail. Can you have a look? |
|
@DaanHoogland the test failures are unrelated to the changes in this PR. Most of the GHI tests are failing due to an error with Codecov, which is also happening in other PRs, such as #8890. The only exceptions are two failures in And the two tests that failed in the last run are failing in other unrelated PRs as well: #8511 (comment). |
|
@blueorangutan package |
|
@winterhazel a [SL] 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. |
|
Packaging result [SF]: ✔️ el7 ✔️ el8 ✔️ el9 ✔️ debian ✔️ suse15. SL-JID 9425 |
|
@DaanHoogland GHI tests are passing now ;) Can you run the CI one last time so we can proceed with this PR? |
|
@blueorangutan test |
|
@DaanHoogland a [SL] Trillian-Jenkins test job (centos7 mgmt + kvm-centos7) has been kicked to run smoke tests |
|
[SF] Trillian test result (tid-10052)
|
|
@blueorangutan test |
|
@DaanHoogland a [SL] Trillian-Jenkins test job (centos7 mgmt + kvm-centos7) has been kicked to run smoke tests |
|
[SF] Trillian test result (tid-10070)
|
|
@DaanHoogland there seems to be a problem with |
yes, see #8931 (comment) and replies |
|
Merging as the tests errors are not related to the PR. |
dhslove
pushed a commit
to ablecloud-team/ablestack-cloud
that referenced
this pull request
Jun 17, 2024
* Normalize dates in Usage and Quota APIs * Apply Daan's sugestions Co-authored-by: dahn <[email protected]> * Restore removed sinces * Add missing space * Change param descriptions for quotaBalance and quotaStatement * Apply Daniel's suggestions Co-authored-by: Daniel Augusto Veronezi Salvador <[email protected]> --------- Co-authored-by: dahn <[email protected]> Co-authored-by: Daniel Augusto Veronezi Salvador <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Description
Dates are always stored in GMT in the database. However, when using the Usage and Quota APIs, dates are manipulated according to the configuration
usage.aggregation.timezone. Therefore, when informing a date, the user must consider the timezone defined in the configuration and the timezone of the server in order to specify a value. Furthermore, if the configuration and the server are not in the same timezone, ACS will not retrieve the data the user requested.This PR changes the behavior of Usage and Quota APIs to consider dates as they were informed. Some examples showing how the current date manipulation may yield unexpected results and how this change fixes them can be found in the tests section.
The APIs affected by this change are:
listUsageRecords: the return of this API was also changed to always return the data in GMT, instead of depending on the timezone of the configuration. This way, it complies with the other APIs and allows users to handle the timezone in the frontend;quotaCredits: when adding credits to an account, the deposit date is now stored in GMT;quotaBalance: in addition, it is now possible to inform anenddatein the future;quotaStatement: it is also now possible to inform anenddatein the future;quotaTariffCreate;quotaTariffDelete:quotaTariffList;quotaTariffUpdate.With the extension that allows users to inform timezones on APIs that have the date parameter (#7032), it is recommended to inform dates in the format
yyyy-MM-dd'T'HH:mm:ssz. When a date is informed inyyyy-MM-dd HH:mm:ssoryyyy-MM-dd, it will be considered that the date was informed in the timezone of the server.Types of changes
Feature/Enhancement Scale or Bug Severity
Bug Severity
Screenshots (if appropriate):
How Has This Been Tested?
In a local lab, I defined
usage.aggregation.timezoneas GMT-3. Then, through CloudMonkey, I verified the behavior of the affected APIs:listUsageRecordsIn this command,
startdateis2023-07-20 18:41:22in GMT, and theenddateis2023-07-20 20:31:22.Current behavior:
The dates get manipulated to
2023-07-20 21:41:22GMT and2023-07-20 23:31:22GMT.After applying the changes:
The command uses the provided dates converted to GMT.
The full response of this command after applying the patch will be posted as a comment, because including it here made the description exceed the maximum amount of characters.
quotaStatementThe
startdateparameter is2023-07-24 23:00:00in GMT.Current behavior:
startdategets manipulated to2023-07-25 02:00:00GMT.After applying the changes:
The command uses the provided
startdatein GMT.Below there is the full response:
quotaCreditsandquotaBalanceCurrent behavior:
The time in GMT was
2023-09-25 19:33:33, butupdated_onwas stored as2023-09-25 22:33:32in the database.After applying the changes:
The time in GMT was
2023-09-26 16:15:35, and the correct value of2023-09-26 16:15:35was stored in the database.quotaTariffCreateAfter applying the changes:
quotaTariffUpdateAfter applying the changes:
quotaTariffListAfter applying the changes:
quotaTariffDeleteAfter applying the changes: