Hacktoberfest 2026: những issue maintainer đã đánh dấu cho tháng Mười, đang mở và phù hợp người mới. Xem issue Hacktoberfest

_job_start_time records the populating host's local time, with no zone

Đang mở
  • Có gì không ổn?
#1,584 0 bình luận 0 reaction 1 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 1 ngày

@dimitri-yatsenko đang làm issue này rồi.

Từ ngày 12/10/2026.

  • #1622 của @dimitri-yatsenko — đang mở

Đánh giá

Issue này chưa được đánh giá.

Mô tả

populate() stores _job_start_time as naive local time on whichever host runs it: start_time = time.time() (autopopulate.py:665), then written as datetime.datetime.fromtimestamp(start_time) (autopopulate.py:742). Two hosts in different time zones write different values for the same instant, and nothing in the row records which zone applies. A populate() run from a laptop in US Central and one from a worker in UTC leave start times five hours apart for computations that ran at the same moment.

The other timestamps the framework writes use a known clock:

  • _prov.time is UTC: datetime.datetime.now(datetime.timezone.utc).isoformat() (provenance.py:103).
  • The job table's completed_time is the server's CURRENT_TIMESTAMP (jobs.py:499, 529).

A reader cannot place _job_start_time on either of those scales unless every host that populates the schema runs in the same zone.

Proposal

  • Take _job_start_time from the server's clock, as the job table already does for completed_time (jobs.py:498-499) and scheduled_time (jobs.py:388). Compute it in the UPDATE that already writes the hidden columns (autopopulate.py:874), as the server's current time minus _job_duration. That adds no round trip, and every host that populates the schema then writes on one clock, whatever zone the host runs in.
  • The server expression must be statement time, not transaction time: NOW(3) on MySQL, and statement_timestamp() on PostgreSQL, where CURRENT_TIMESTAMP is the start of the transaction. It belongs in the adapter, beside current_user_expr().
  • Keep measuring _job_duration on the worker. It is a difference of two readings on one clock, so neither zone nor skew affects it. The UPDATE runs after the commit that _job_duration already includes, so the derived start is late by the one-way latency of that statement, which is the same error a separate SELECT at start would carry.
  • State in job-metadata.md (datajoint-docs) that _job_start_time uses the server's clock from the release that ships the change, and that rows written earlier carry the populating host's local time. Those rows cannot be corrected after the fact, because the zone was never recorded.
Ngôn ngữ chính
Python
Star
197
Fork
99
Merge trung bình
2 ngày 10 giờ
Pull request đã merge (30 ngày)
12

Chuẩn bị môi trường

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của datajoint/datajoint-python

Tất cả issue của datajoint/datajoint-python

Issue tương tự

Thêm issue về Python

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.