Feature: TDD Bug #10483 — LockService.acquire() must use datetime comparison for lock expiry
  As a developer using LockService
  I want lock expiry to be determined by comparing datetime objects
  So that non-expired locks held by other owners are not incorrectly treated as expired

  # This test captures bug #10483. The previous implementation converted
  # expires_at to a string via str() and compared it lexicographically
  # against an ISO 8601 string produced by isoformat().
  #
  # The bug: str(naive_datetime) uses a space separator (e.g. '2026-04-19 06:00:00')
  # while isoformat() uses 'T' (e.g. '2026-04-19T05:30:18+00:00').
  # Since space (ASCII 32) < 'T' (ASCII 84), the comparison
  # str(naive_datetime) >= now_iso was ALWAYS False regardless of whether
  # the lock had actually expired. This meant a non-expired lock held by
  # another owner was silently treated as expired, allowing lock theft.
  #
  # The fix replaces the fragile string comparison with a proper datetime
  # comparison that normalises timezone info before comparing.

  @tdd_issue @tdd_issue_10483
  Scenario: Bug #10483 — non-expired lock with naive datetime expires_at is not incorrectly treated as expired
    Given a lock service with a real database for tdd 10483
    And a non-expired lock exists with a naive datetime expires_at for tdd 10483
    When a different owner tries to acquire the same resource for tdd 10483
    Then a LockConflictError should be raised because the lock is still active for tdd 10483

  @tdd_issue @tdd_issue_10483
  Scenario: Bug #10483 — non-expired lock with ISO string expires_at is not incorrectly treated as expired
    Given a lock service with a real database for tdd 10483
    And a non-expired lock exists with an ISO string expires_at for tdd 10483
    When a different owner tries to acquire the same resource for tdd 10483
    Then a LockConflictError should be raised because the lock is still active for tdd 10483
