advance_virtual_datetime_m Sample Call and Response
This example shows you how to advance the virtual system date and time for a non-production client by a specified number of hours, using the plsql_m_r73.yml definition for release seventy-three of the Aria Billing Cloud Core API.
This example covers a single call that advances virtual time by seventy-two hours. It does not cover calling this method against a production client, which Aria rejects with an operation-not-allowed error.
Sample call
{
"rest_call": "advance_virtual_datetime_m",
"output_format": "json",
"client_no": 3001,
"auth_key": "a1b2c3d4e5f6g7h8i9j0k1l2m3n4o5p6",
"offset_hours": 72
}
The offset_hours field is required and must be a positive integer; this example advances the client's current virtual time by seventy-two hours to simulate three days passing for testing purposes, such as verifying that recurring billing runs correctly. This method takes only these three inputs beyond the envelope fields, so there are no optional fields or alternative-field groups to choose between.
Sample response
{
"error_code": 0,
"error_msg": "OK",
"virtual_date": "2026-07-27",
"virtual_time": "09:14:00",
"system_date": "2026-07-24",
"system_time": "09:14:00",
"current_offset_hours": 72
}
An error_code value of zero, together with an error_msg value of "OK", indicates that Aria advanced the virtual time successfully. The virtual_date and virtual_time fields show the client's current virtual system date and time after applying offset_hours, while system_date and system_time show the actual, real-world system date and time for comparison. The current_offset_hours field shows the resulting difference, in whole hours, between virtual time and actual time after this call, which in a non-production system is always zero or a positive integer. This method also defines an error_details field in its returns, but Aria marks that field nonpublic, so this example leaves it out entirely.