Loyal-Young opened a new issue, #6896:
URL: https://github.com/apache/rocketmq-dashboard/issues/6896
### Before Creating the Bug Report
- [x] I searched the open issues and pull requests for an export filename
date/timezone fix.
- [x] This is a RocketMQ Studio defect on the current `rocketmq-studio`
branch.
### Studio Version
`rocketmq-studio` at `a92c23144408cdf5729707050e9ecd9b75f1bad0`.
### Runtime Environment
Any browser outside UTC near a local midnight. Reproduced with Node 20 under
`TZ=Asia/Shanghai` and `TZ=America/Los_Angeles`; no broker or database is
needed.
### Describe the Bug
Ten Studio export entry points build their dated CSV filename with `new
Date().toISOString().slice(0, 10)`. `toISOString()` changes the instant to UTC
before taking the date. For an operator in UTC+8 at 2026-10-17 00:30 local,
this stamps the file `2026-10-16`; in UTC-7 at 2026-10-16 20:30 local, it
stamps the file `2026-10-17`.
Affected exports include instance topics and consumer groups, client and
producer connections, Lite Topics, broker/NameServer/proxy topology, Studio
users, data sources, cloud credentials, and system alerts. The audit exports
already use local `dayjs().format('YYYY-MM-DD')`, so the UI produces
inconsistent dates for files downloaded at the same local time.
### Steps to Reproduce
1. Set the browser timezone to `Asia/Shanghai` and the clock to `2026-10-17
00:30` local (`2026-10-16T16:30:00Z`).
2. Export users, topics, or any affected CSV.
3. Observe that the filename ends in `2026-10-16.csv` even though the local
calendar date is October 17.
The same date disagreement can be reproduced without the UI: under
`TZ=Asia/Shanghai`, `new Date('2026-10-16T16:30:00Z').toISOString().slice(0,
10)` is `2026-10-16`, while local date parts are October 17.
### What Did You Expect to See?
Dated export filenames use the operator's local calendar date, matching the
other export actions and the date shown by the browser.
### What Did You See Instead?
Some exported files are named for the previous or next UTC date around local
midnight.
### Additional Context
I have a focused fix that reuses the existing local `formatDate` helper and
unit regressions for positive and negative UTC offsets. Export contents and
timestamp columns remain unchanged.
### Are You Willing to Submit a Pull Request?
- [x] Yes.
--
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]
