Skip to content

fix: show events starting at Unix timestamp 0#1240

Open
MiMoHo wants to merge 1 commit into
FossifyOrg:mainfrom
MiMoHo:fix/issue-440
Open

fix: show events starting at Unix timestamp 0#1240
MiMoHo wants to merge 1 commit into
FossifyOrg:mainfrom
MiMoHo:fix/issue-440

Conversation

@MiMoHo

@MiMoHo MiMoHo commented Jul 3, 2026

Copy link
Copy Markdown

Type of change(s)

  • Bug fix

What changed and why

Several EventsDao queries carried a stale AND start_ts != 0 clause inherited from the Simple Calendar era. start_ts is a Unix timestamp in seconds, so start_ts == 0 is exactly 1970-01-01 00:00:00 UTC. Any event landing on that instant — including all-day or yearly-recurring events whose start falls on epoch 0 (e.g. New Year's Day 1970 in GMT+0) — was stored in the database but silently filtered out of day/list views, search, and reboot reminder rescheduling, so it never became visible.

The clause was also inconsistent: the sibling queries without calendarIds (getOneTimeEventsOrTasksFromTo, getRepeatableEventsOrTasksWithCalendarIds(toTS)) never had it, confirming it is a legacy heuristic rather than intentional behaviour. No code inserts start_ts = 0 as a hidden sentinel (only the Event model default 0L and the UI-only ListEvent.empty).

This PR removes the clause from the five affected queries:

  • getOneTimeEventsFromToWithCalendarIds
  • getOneTimeEventsFromToWithTypesForSearch
  • getRepeatableEventsOrTasksWithCalendarIds(toTS, calendarIds)
  • getRepeatableEventsOrTasksWithTypesForSearch
  • getEventsOrTasksAtReboot

Removing it from the reboot query is safe: a non-repeating event at ts 0 is already excluded by (start_ts > :currentTS OR repeat_interval != 0), while a repeating one legitimately has future occurrences that need reminders. The now-obsolete legacy comment above that query is dropped.

The existing instrumented test bug440_EventAtMidnightOnFirstJan1970 (previously wrapped in expectedFailure) is unwrapped so it now passes, and the detekt baseline is updated to match the shortened query lines.

Tests performed

Built the fossDebug variant and verified on an Android 15 (API 35) emulator:

Set device timezone to UTC (Etc/GMT); created event at Jan 1 1970 12:00 AM (start_ts=0). Reminder notification fired showing 'January 1 1970, 12:00 AM'. Searching 'Epoch' returned the event under JANUARY 1970 / 1 Thursday / Epoch 12:00 AM. Previously start_ts!=0 filter would hide it.

Also confirmed detekt, lint, unit tests and the build all pass locally (CI-equivalent).

Closes the following issue(s)

Checklist

  • I read the contribution guidelines.
  • I manually tested my changes on device/emulator.
  • I updated the "Unreleased" section in CHANGELOG.md (if applicable).
  • I have self-reviewed my pull request (no typos, formatting errors, etc.).
  • I understand every change in this pull request.

Coded with Opus 4.8 ultracode.

Several EventsDao queries carried a stale `start_ts != 0` clause from the Simple Calendar era. Because start_ts is a Unix timestamp in seconds, start_ts == 0 is exactly 1970-01-01 00:00:00 UTC, so any event at that instant (including all-day or yearly-recurring events whose start lands on epoch 0) was stored in the DB but never shown in day/search views nor rescheduled at reboot.

Remove the clause from the five affected queries (one-time, one-time search, repeatable, repeatable search, and the reboot reminder query). Removing it from the reboot query is safe: a non-repeating event at ts 0 is still excluded by (start_ts > :currentTS OR repeat_interval != 0). Unwrap the existing bug440 instrumented test so it now passes and update the detekt baseline.

Closes FossifyOrg#440
@MiMoHo MiMoHo requested a review from naveensingh as a code owner July 3, 2026 21:29
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Events starting on the timestamp 0 aren't visible in the app

1 participant