Skip to main content

Short answer

Pick your local timezone

Users in China pick Asia/Shanghai (UTC+8); everyone else picks their local timezone. Once set, every time you see is your local time

Accept the suggestion dialog

When the console detects a different device timezone it shows a “本地设置建议” (Local Settings Suggestion) dialog — just click the switch button

One basis everywhere

The detail list, the chart, Export and Billing Summary all use the account timezone, so no conversion is needed between them
The chart misalignment was fixed at 2026/9/20 00:55 (UTC+8). Previously, when the account timezone was not UTC, the 调用数据一览 (Call Data Overview) chart at the top of the Logs page put data on the wrong day (for example, a bar for the next day appearing in the afternoon, Beijing time). That is why we used to recommend staying on UTC+0 and dismissing the dialog. The issue is fixed and that advice is withdrawn — please pick your own timezone.
The rule in one line: everything you see or export in the console (detail list, chart, export files, Billing Summary) follows your account timezone; what you pull programmatically (created_at from the Log Query API) is a Unix second timestamp, independent of any timezone.

Where to check and change your account timezone

The account timezone is shown and edited in the 用户信息 (User Info) section of the console. New accounts default to UTC; users in China should switch to Asia/Shanghai.
The timezone setting in the console User Info section

The timezone setting in the console's User Info section — change it from the dropdown

Switching the timezone only changes how times are displayed and grouped. No call record or charge is modified or lost, and you can change it back at any time.

Accept the switch when the suggestion dialog appears

When your account timezone (for example UTC) differs from your current device timezone (for example Asia/Shanghai), the console opens a “本地设置建议” (Local Settings Suggestion) dialog. Just click the switch button on the right. The detail list and the chart then show Beijing time.
Local Settings Suggestion dialog showing account timezone UTC and device timezone Asia/Shanghai, with Dismiss and Switch buttons

The Local Settings Suggestion dialog — you can click the switch button directly

If your finance team reconciles strictly in UTC, you can dismiss the dialog and stay on UTC instead. Both choices display correctly now, so pick whichever matches your reconciliation process. The 调用数据一览 (Call Data Overview) chart at the top of the Logs page buckets data by calendar day in the account timezone:
The Call Data Overview entry at the top of the console Logs page, outlined in red

The Call Data Overview at the top of the Logs page, bucketed by day in the account timezone

Which export should you use?

The Logs page has two buttons in the top-right corner, 导出 (Export) and 汇总账单 (Billing Summary).
Logs page toolbar with the Export button on the left and the Billing Summary button on the right

The Export and Billing Summary buttons in the top-right corner of the Logs page

Both buttons use the same timezone basis and differ only in granularity and volume. Pick whichever matches what you need — individual records or aggregated totals. For example, with the account set to Asia/Shanghai, a call made at 2026-09-20 01:08 (UTC+8):
  • shows as 2026-09-20 01:08 in the page detail list
  • shows as 2026/9/20 1:08 in the export file as well
  • falls under 2026-09-20 in the Billing Summary (daily) and on September 20 in the chart
The first 14 digits of a request ID are UTC time. For example 20260919170811… means 2026-09-19 17:08:11 UTC, i.e. 2026-09-20 01:08:11 (UTC+8). When checking a specific call with support, the request ID is the most precise reference.
When you need line-by-line spend records, use the 导出 (Export) button and pick 后台异步导出 (background async export) in the dialog.
Export dialog showing selectable fields, current-page versus background async export, Excel and CSV formats, and a maximum record count

The export dialog — select background async export for large volumes

Key points:
  • Times are written in the account timezone, matching the page detail list
  • Selectable fields: usage time, request ID, token name, model name and more — pick what your reconciliation needs
  • Export mode: for large volumes choose background async export; the job runs in the background without blocking the page, and it is recommended above 10,000 records
  • Format: Excel (.xlsx, very large exports are split and zipped automatically) or CSV (.csv, for small volumes)
  • Maximum record count: 0 means unlimited (the server splits into multiple Excel files and zips them), with a ceiling of 50 million records
  • Progress: once the job is created, track its progress and status on the 任务管理 (Task Management) page, then download the file
For the full export walkthrough and archiving advice, see How long are call logs kept?.

Reconciliation in practice

1

Make sure both sides use the same timezone

Export files group dates by the exporting account’s timezone. When several people reconcile, or when you match against a finance system, first confirm everyone uses the same timezone (for example Asia/Shanghai); otherwise calls made around midnight land on different dates.
2

Convert API timestamps yourself

created_at from the Log Query API is a Unix second timestamp; convert it to whatever timezone you need. For Beijing time, add 28800 (8 × 3600) and format as UTC, or use your language’s timezone library.
3

Include the request ID and timezone when reporting an issue

The request ID carries UTC time and is the least error-prone reference; when quoting a time, always state the timezone, such as 01:08 (UTC+8).
For reconciliation or audit work that has to be split by business day, you can also use the Log Query API with your own script, which gives you more control than export files.

Common questions

No. That advice existed because the chart put data on the wrong day when the account timezone was not UTC. The issue was fixed at 2026/9/20 00:55 (UTC+8). Please pick your own timezone now.
We recommend switching to Asia/Shanghai so that every time in the console is Beijing time and you no longer add 8 hours by hand. If your reconciliation process is fixed on UTC, staying on UTC is fine too — both display correctly now.
No. The timezone only affects how times are displayed and grouped by date. No call record or charge is modified, and you can switch back at any time.
Every record and amount in a line-by-line export (the Export button) is accurate, with times shown in the account timezone at that moment. For Billing Summary files and chart data before 2026/9/20 00:55 (UTC+8), the daily or hourly grouping may be shifted by 8 hours, while the totals are unaffected. If you need an exact per-day reconciliation, export again.
Most likely your account timezones differ. Export files use the exporting account’s timezone — confirm both accounts use the same one under User Info.
No. The API only accepts and returns Unix second timestamps, which are UTC by definition. Convert client-side as needed.
No. The exported fields match what the console shows — time, request ID, token name, model, token counts, amount, status — with no prompts or model output. See How long are call logs kept?.
Yes, see the Log Query API. Its start_timestamp, end_timestamp and created_at are all Unix second timestamps, independent of the console timezone setting — a good fit for automated reconciliation.
First check the job status on the 任务管理 (Task Management) page. For very large volumes (millions of records) the server needs time to split and package the files; narrow the time range or set a sensible maximum record count and export in batches.