Hacktoberfest 2026：メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

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

オープン
  • 何か問題がありますか？
#1,584 コメント 0 件 リアクション 0 件 担当者 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
フォーク
99
平均マージ
1日 11時間
マージ済み PR（30日）
10

環境構築

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

datajoint/datajoint-python のほかの issue

datajoint/datajoint-python の issue をすべて見る

似ている issue

Python の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。