What did you do?

Consider a DM source whose upstream timezone is UTC and an operator in UTC+8 starting incremental replication with a wall-clock time such as 2026-04-17 08:00:00.

Current behavior across the start-task paths is:

1. dmctl / OpenAPI only accept bare start_time values without timezone information.
2. The backend parses a bare start_time in the upstream timezone when resolving the binlog position.
3. The DM UI currently converts the selected local time to UTC and then sends a bare timestamp string, which drops the original timezone offset.

That means a user intent like “my local 2026-04-17 08:00:00 in UTC+8” can end up being interpreted as upstream-local 2026-04-17 08:00:00 UTC, shifting the effective start point by hours.

What did you expect to see?

start_time should support timezone-aware values, for example RFC3339 timestamps with offsets such as 2026-04-17T08:00:00+08:00, so DM can resolve the intended absolute time correctly.

For backward compatibility, legacy bare timestamps can continue to be interpreted in the upstream timezone.

What did you see instead?

start_time loses the caller's timezone context. In cross-timezone scenarios, DM can resolve the wrong binlog start position.

Versions of the cluster

DM version (run dmctl -V or dm-worker -V or dm-master -V):

Observed on current master branch.

Upstream MySQL/MariaDB server version:

Any timezone-aware upstream where the source timezone differs from the caller timezone.

Downstream TiDB cluster version (execute SELECT tidb_version(); in a MySQL client):

N/A for the parsing issue itself.

How did you deploy DM: tiup or manually?

Not deployment-specific.

Other interesting information (system version, hardware config, etc):

The affected code paths include dmctl/OpenAPI validation, syncer start_time parsing, and the DM UI start-task request payload formatting.