Hacktoberfest 2026: as issues que os mantenedores marcaram para outubro, abertas e boas para iniciantes. Ver issues do Hacktoberfest

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

Aberta
  • Algo errado?
#1,584 0 comentários 0 reações 1 responsável Ver no GitHub

Mantenedores costumam responder em até 1 dia

@dimitri-yatsenko já está trabalhando nisso.

Desde 12/10/2026.

Avaliação

Esta issue ainda não foi avaliada.

Descrição

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.
Linguagem predominante
Python
Estrelas
197
Forks
98
Merge médio
15h 31min
PRs com merge (30d)
9

Preparar o ambiente

Primeiros passos

  1. Leia a issue inteira e depois o guia de contribuição do projeto.
  2. Comente na issue dizendo que vai assumir — evita que duas pessoas façam o mesmo trabalho.
  3. Faça um fork do repositório e trabalhe em uma branch.
  4. Abra um pull request que referencie o número da issue.

Mais de datajoint/datajoint-python

Todas as issues de datajoint/datajoint-python

Issues semelhantes

Mais issues de Python

Receba novas issues na sua caixa de entrada

Um resumo curto de issues do GitHub para quem está começando.