Hacktoberfest 2026：維護者為十月標記出來的 issue，仍然開放、適合新手。 瀏覽 Hacktoberfest issue

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

未關閉
  • 哪裡不對？
#1,584 0 則留言 0 個 reaction 已指派 1 人 在 GitHub 檢視

維護者通常 1 天內回覆

@dimitri-yatsenko 已經在處理了。

開始於 2026年10月12日。

評估

這個 Issue 還沒有評估資料。

描述

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.
主要語言
Python
星號
197
分支
98
平均合併
15 小時 31 分鐘
30 天內合併 PR
9

環境準備

  • 提供 Dockerfile 或 Docker Compose 檔案
  • 沒有 Pull Request 範本
  • 閱讀貢獻指南

從這裡開始

  1. 先讀完整個 Issue，再讀專案的貢獻指南。
  2. 在 Issue 下留言說明你要接手 —— 這能避免兩個人做同樣的事。
  3. Fork 儲存庫，在一個分支上完成修改。
  4. 送出 Pull Request，並在描述裡引用這個 Issue 編號。

datajoint/datajoint-python 的其他 Issue

查看 datajoint/datajoint-python 的全部 Issue

相似的 Issue

更多 Python Issue

把新 issue 寄到你的電子郵件信箱

精選適合新手參與的 GitHub issue 摘要。