unbridled-41 opened a new issue, #5887:
URL: https://github.com/apache/rocketmq-dashboard/issues/5887
### Studio Version
branch: `rocketmq-studio` @ `7e7aa344` (the revision verified; the branch is
based on it)
deployed as: the repository's own compose deployment
(`deploy/docker-compose.yml`)
### Runtime Environment
Reproduced with the backend unit tests (`cd server && mvn -o -B -ntp test
-Dtest='AuthServiceDatabaseTest'`). The live effect depends on one deployment
fact that is checked in to this repository: `deploy/docker-compose.yml` sets
`TZ: ${TZ:-Asia/Shanghai}` on both the MySQL and the server container and pins
`serverTimezone=Asia/Shanghai`. CI's MySQL service container has no `TZ`, i.e.
runs in UTC, which is why the suite cannot see it.
### Connected RocketMQ Cluster
Not involved. The rows live in Studio's own `rmq_studio_user` and
`rmq_studio_session` tables.
### Describe the Bug
`AuthService` stamps every timestamp of the user and session rows from its
own UTC clock - `passwordChangedAt`, `lastSeenAt`, `expiresAt` - except the two
audit columns, which it leaves null so that MySQL's column default fills them:
```sql
-- server/src/main/resources/db/schema.sql:33-34
`gmt_create` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '创建时间',
`gmt_modified` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE
CURRENT_TIMESTAMP COMMENT '修改时间',
```
MyBatis-Plus's default insert strategy omits null fields and there is no
`MetaObjectHandler` in `server/src/main`, so `CURRENT_TIMESTAMP` is evaluated
in the database session's zone - the server's local zone, not UTC. The console,
however, parses those fields as UTC:
```ts
// web/src/pages/studio/UserManagement.tsx:78
// Studio user and session APIs serialize UTC LocalDateTime values without
an offset,
// so the timestamps have to be parsed as UTC before rendering in the
viewer's zone.
```
and `docs/api-spec.md` states the contract as "ISO-8601，无时区偏移的 UTC".
On the documented deployment the Users page therefore prints a creation time
eight hours in the future for every account, the session drawer's "Created"
column is shifted the same way, and the two CSV exports (`Created At`,
`Modified At`) inherit it. The same row also carries `passwordChangedAt`, which
*is* UTC, so one row shows "Created 18:00" next to "Password changed 10:00" for
one and the same event.
### Steps to Reproduce
1. Start the compose deployment (or any MySQL whose session zone is not UTC)
and create a Studio user.
2. Open Studio → Settings → Users.
3. Compare the "Created" column with "Password Changed At" of the same row,
or with the wall clock in a browser set to UTC.
Measured zone split on an H2 database using the repository's schema shape,
JVM zone `Asia/Shanghai`:
```
stored gmt_create (DB default) = 2026-10-10T00:08:44
stored last_seen_at (app UTC) = 2026-10-09T16:08:43 -> delta 8 hours
```
### What Did You Expect to See?
The creation/modification instants the API returns for a row are UTC
instants, like every other zone-less timestamp that API serializes.
### What Did You See Instead?
An instant that depends on where MySQL runs; eight hours in the future in
the documented deployment, so a freshly created account looks like it was
created later today and the CSV export records the same wrong value.
### Evidence
-
`server/src/main/java/org/apache/rocketmq/studio/auth/AuthService.java:305-315`
(`createUser`), `:409-414` (`loginDatabaseUser`), `:485-495`
(`ensureBootstrapUsers`); `AuthService.java:633-635` (`now()` = UTC).
- `server/src/main/resources/db/schema.sql:33-34`, `:47-48`;
`deploy/docker-compose.yml` (`TZ`, `serverTimezone`).
- `web/src/pages/studio/UserManagement.tsx:78-81`, `:398`, `:458` and the
export columns at `:102-104`.
- `cd server && mvn -o -B -ntp test
-Dtest='org.apache.rocketmq.studio.auth.*Test'` - 155 tests pass before and
after; the suite has no assertion on the audit columns of an inserted row.
### Impact
Wrong creation and modification times for every Studio account and session
on any deployment whose database zone is not UTC; the wrong value is also what
the users CSV export and the sessions CSV export contain, and it contradicts a
sibling field of the same row.
### Acceptance Criteria
- The service stamps `gmt_create`/`gmt_modified` from its UTC clock on both
insert paths and keeps `gmt_modified` on the password-change update in the same
zone, with a regression test per path.
- A reviewer can reproduce the offset by running the documented deployment
or the fixed-clock unit test.
**Corresponding PR:** #5886
--
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]
