Hacktoberfest 2026: die Issues, die Maintainer für den Oktober markiert haben – offen und einsteigerfreundlich. Hacktoberfest-Issues durchsuchen

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

Offen
  • Stimmt etwas nicht?
#1,584 0 Kommentare 0 Reaktionen 1 zugewiesene Person Auf GitHub ansehen

Maintainer antworten meist innerhalb von 1 Tag

@dimitri-yatsenko arbeitet bereits daran.

Seit 12.10.2026.

  • #1622 von @dimitri-yatsenko — offen

Bewertung

Dieses Issue wurde noch nicht bewertet.

Beschreibung

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.
Vorherrschende Sprache
Python
Sterne
197
Forks
99
Ø Merge
2 T. 10 Std.
Gemergte PRs (30 T.)
12

Entwicklungsumgebung

Erste Schritte

  1. Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
  2. Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
  3. Forken Sie das Repository und arbeiten Sie in einem Branch.
  4. Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.

Mehr aus datajoint/datajoint-python

Alle Issues in datajoint/datajoint-python

Ähnliche Issues

Weitere Issues zu Python

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.