fix(repositories): standardize all timestamp generation to timezone-aware UTC in repositories.py #3679

Open
opened 2026-04-05 21:30:49 +00:00 by freemo · 1 comment
Owner

Metadata

  • Branch: fix/repositories/utc-timestamp-consistency
  • Commit Message: fix(repositories): standardize all timestamp generation to timezone-aware UTC in repositories.py
  • Milestone: None (Backlog)
  • Parent Epic: #362

Background

src/cleveragents/infrastructure/database/repositories.py inconsistently uses both naive datetime.now() (no timezone) and timezone-aware datetime.now(tz=UTC) for timestamp generation. This creates data inconsistency where some timestamps are stored as naive local-time datetimes and others as UTC-aware ISO strings.

The newer repositories (ResourceTypeRepository, ResourceRepository, NamespacedProjectRepository, etc.) correctly use datetime.now(tz=UTC). The legacy repositories (ProjectRepository, PlanRepository, ActorRepository, ActionRepository, ChangeRepository, ValidationAttachmentRepository) still use the naive datetime.now() form.

Problem

9 occurrences of naive datetime.now() exist alongside 14 occurrences of datetime.now(tz=UTC):

Naive (incorrect) calls:

  • Line 232: db_project.updated_at = datetime.now()ProjectRepository.update()
  • Line 328: db_plan.updated_at = datetime.now()PlanRepository.update()
  • Line 594: {"applied": True, "applied_at": datetime.now()}ChangeRepository.mark_applied()
  • Line 762: existing.updated_at = datetime.now()ActorRepository.upsert()
  • Line 809: {"is_default": False, "updated_at": datetime.now()}ActorRepository.clear_default()
  • Line 821: db_actor.updated_at = datetime.now()ActorRepository.set_default()
  • Line 1098: row.updated_at = datetime.now().isoformat()ActionRepository.update()
  • Line 1131: now_iso = datetime.now().isoformat()ActionRepository.update()
  • Line 3821: now_iso = datetime.now().isoformat()ValidationAttachmentRepository.attach()

Timezone-aware (correct) calls use datetime.now(tz=UTC) in ResourceTypeRepository, ResourceRepository, NamespacedProjectRepository, etc.

Impact

Timestamps from legacy repositories (ProjectRepository, PlanRepository, ActorRepository, ActionRepository) will be stored as local-time naive datetimes, while newer repositories store UTC-aware timestamps. This causes inconsistent sorting, comparison, and display of timestamps across the application.

Subtasks

  • Replace all 9 naive datetime.now() calls with datetime.now(tz=UTC) in src/cleveragents/infrastructure/database/repositories.py
  • Verify UTC is imported from datetime module (or timezone.utc alias) at the top of the file
  • Update ActionRepository.update() (lines 1098, 1131) to use datetime.now(tz=UTC).isoformat() instead of datetime.now().isoformat()
  • Update ValidationAttachmentRepository.attach() (line 3821) to use datetime.now(tz=UTC).isoformat()
  • Tests (Behave): Add/update scenarios verifying that all timestamp fields written by the affected repositories are timezone-aware UTC
  • Tests (Robot): Verify integration-level timestamp consistency across repositories
  • Run nox -e typecheck — confirm Pyright passes with no errors
  • Run nox -e lint — confirm linting passes
  • Verify coverage >= 97% via nox -s coverage_report
  • Run nox (all default sessions), fix any errors

Definition of Done

This issue is complete when:

  • All subtasks above are completed and checked off.
  • All 9 naive datetime.now() calls in repositories.py have been replaced with datetime.now(tz=UTC).
  • No naive datetime timestamps are written to the database by any repository.
  • A Git commit is created where the first line of the commit message matches the Commit Message in Metadata exactly, followed by a blank line, then additional lines providing relevant details about the implementation.
  • The commit is pushed to the remote on the branch matching the Branch in Metadata exactly.
  • The commit is submitted as a pull request to master, reviewed, and merged before this issue is marked done.
  • All nox stages pass.
  • Coverage >= 97%.

Backlog note: This issue was discovered during autonomous operation
on milestone v3.3.0. It does not block milestone completion and has been
placed in the backlog for human review and future milestone assignment.


Automated by CleverAgents Bot
Supervisor: UAT Testing | Agent: ca-new-issue-creator

## Metadata - **Branch**: `fix/repositories/utc-timestamp-consistency` - **Commit Message**: `fix(repositories): standardize all timestamp generation to timezone-aware UTC in repositories.py` - **Milestone**: None (Backlog) - **Parent Epic**: #362 ## Background `src/cleveragents/infrastructure/database/repositories.py` inconsistently uses both naive `datetime.now()` (no timezone) and timezone-aware `datetime.now(tz=UTC)` for timestamp generation. This creates data inconsistency where some timestamps are stored as naive local-time datetimes and others as UTC-aware ISO strings. The newer repositories (`ResourceTypeRepository`, `ResourceRepository`, `NamespacedProjectRepository`, etc.) correctly use `datetime.now(tz=UTC)`. The legacy repositories (`ProjectRepository`, `PlanRepository`, `ActorRepository`, `ActionRepository`, `ChangeRepository`, `ValidationAttachmentRepository`) still use the naive `datetime.now()` form. ## Problem **9 occurrences of naive `datetime.now()`** exist alongside **14 occurrences of `datetime.now(tz=UTC)`**: Naive (incorrect) calls: - Line 232: `db_project.updated_at = datetime.now()` — `ProjectRepository.update()` - Line 328: `db_plan.updated_at = datetime.now()` — `PlanRepository.update()` - Line 594: `{"applied": True, "applied_at": datetime.now()}` — `ChangeRepository.mark_applied()` - Line 762: `existing.updated_at = datetime.now()` — `ActorRepository.upsert()` - Line 809: `{"is_default": False, "updated_at": datetime.now()}` — `ActorRepository.clear_default()` - Line 821: `db_actor.updated_at = datetime.now()` — `ActorRepository.set_default()` - Line 1098: `row.updated_at = datetime.now().isoformat()` — `ActionRepository.update()` - Line 1131: `now_iso = datetime.now().isoformat()` — `ActionRepository.update()` - Line 3821: `now_iso = datetime.now().isoformat()` — `ValidationAttachmentRepository.attach()` Timezone-aware (correct) calls use `datetime.now(tz=UTC)` in `ResourceTypeRepository`, `ResourceRepository`, `NamespacedProjectRepository`, etc. ## Impact Timestamps from legacy repositories (`ProjectRepository`, `PlanRepository`, `ActorRepository`, `ActionRepository`) will be stored as local-time naive datetimes, while newer repositories store UTC-aware timestamps. This causes inconsistent sorting, comparison, and display of timestamps across the application. ## Subtasks - [ ] Replace all 9 naive `datetime.now()` calls with `datetime.now(tz=UTC)` in `src/cleveragents/infrastructure/database/repositories.py` - [ ] Verify `UTC` is imported from `datetime` module (or `timezone.utc` alias) at the top of the file - [ ] Update `ActionRepository.update()` (lines 1098, 1131) to use `datetime.now(tz=UTC).isoformat()` instead of `datetime.now().isoformat()` - [ ] Update `ValidationAttachmentRepository.attach()` (line 3821) to use `datetime.now(tz=UTC).isoformat()` - [ ] Tests (Behave): Add/update scenarios verifying that all timestamp fields written by the affected repositories are timezone-aware UTC - [ ] Tests (Robot): Verify integration-level timestamp consistency across repositories - [ ] Run `nox -e typecheck` — confirm Pyright passes with no errors - [ ] Run `nox -e lint` — confirm linting passes - [ ] Verify coverage >= 97% via `nox -s coverage_report` - [ ] Run `nox` (all default sessions), fix any errors ## Definition of Done This issue is complete when: - All subtasks above are completed and checked off. - All 9 naive `datetime.now()` calls in `repositories.py` have been replaced with `datetime.now(tz=UTC)`. - No naive datetime timestamps are written to the database by any repository. - A Git commit is created where the **first line** of the commit message matches the Commit Message in Metadata exactly, followed by a blank line, then additional lines providing relevant details about the implementation. - The commit is pushed to the remote on the branch matching the **Branch** in Metadata exactly. - The commit is submitted as a **pull request** to `master`, reviewed, and **merged** before this issue is marked done. - All nox stages pass. - Coverage >= 97%. > **Backlog note:** This issue was discovered during autonomous operation > on milestone v3.3.0. It does not block milestone completion and has been > placed in the backlog for human review and future milestone assignment. --- **Automated by CleverAgents Bot** Supervisor: UAT Testing | Agent: ca-new-issue-creator
Author
Owner

Issue triaged by project owner:

  • State: Verified
  • Priority: Backlog — Data consistency issue but doesn't cause immediate failures. Timestamps are still stored, just inconsistently.
  • Milestone: None (backlog)
  • Story Points: 2 — S — 9 straightforward find-and-replace changes from datetime.now() to datetime.now(tz=UTC) in a single file.
  • MoSCoW: Should Have — Timestamp consistency is important for data integrity, sorting, and cross-timezone correctness. The fix is simple and low-risk.
  • Parent Epic: #362

Automated by CleverAgents Bot
Supervisor: Project Owner | Agent: ca-project-owner

Issue triaged by project owner: - **State**: Verified - **Priority**: Backlog — Data consistency issue but doesn't cause immediate failures. Timestamps are still stored, just inconsistently. - **Milestone**: None (backlog) - **Story Points**: 2 — S — 9 straightforward find-and-replace changes from `datetime.now()` to `datetime.now(tz=UTC)` in a single file. - **MoSCoW**: Should Have — Timestamp consistency is important for data integrity, sorting, and cross-timezone correctness. The fix is simple and low-risk. - **Parent Epic**: #362 --- **Automated by CleverAgents Bot** Supervisor: Project Owner | Agent: ca-project-owner
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Blocks
#362 Epic: Security & Safety Hardening
cleveragents/cleveragents-core
Reference
cleveragents/cleveragents-core#3679
No description provided.