eventsNow is listing additional entries (ignoring timezones?)

[jjhidalgar-celonis]

Here is an example:

Now: Thu Jul 3 10:21:24 CEST 2025 (Madrid)

[
  {
    "account": "Google",
    "type": "CalDAV",
    "color": "#9FE1E7FF",
    "calendar": "REDACTED",
    "subcal_url": null,
    "symbolic_color_name": "custom",
    "end_date": 773224200,
    "orig_date": 773222400,
    "start_date": 773222400,
    "duration": 1800,
    "all_day": 0,
    "availability": 0,
    "conference_url_detected": null,
    "notes": "REDACTED",
    "has_recurrences": 0,
    "invitation_status": 0,
    "orig_item_id": 2198,
    "ROWID": 2401,
    "start_tz": "Europe/Madrid",
    "status": 1,
    "title": "ONGOING EVENT ",
    "unique_identifier": "REDACTED",
    "url": null,
    "UUID": "REDACTED",
    "xdate": [
      null
    ],
    "attendees": [
      "REDACTED"
    ],
    "address": null,
    "location": null,
    "count": null,
    "rend_date": null,
    "frequency": null,
    "interval": null,
    "specifier": null,
    "trigger_interval": -600,
    "eseconds": 1751531400,
    "ectime": "2025-07-03 10:30:00 +0200",
    "edate": "today",
    "oseconds": 1751529600,
    "octime": "2025-07-03 10:00:00 +0200",
    "odate": "today",
    "sseconds": 1751529600,
    "sctime": "2025-07-03 10:00:00 +0200",
    "sdate": "today"
  },
  {
    "account": "Google",
    "type": "CalDAV",
    "color": "#9FE1E7FF",
    "calendar": "REDACTED",
    "subcal_url": null,
    "symbolic_color_name": "custom",
    "end_date": 773245800,
    "orig_date": null,
    "start_date": 773244000,
    "duration": 1800,
    "all_day": 0,
    "availability": 0,
    "conference_url_detected": null,
    "notes": "REDACTED",
    "has_recurrences": 1,
    "invitation_status": 0,
    "orig_item_id": 0,
    "ROWID": 2057,
    "start_tz": "America/New_York",
    "status": 1,
    "title": "NOT NOW EVENT",
    "unique_identifier": "REDACTED",
    "url": null,
    "UUID": "REDACTED",
    "xdate": [
      null
    ],
    "attendees": [
      "REDACTED"
    ],
    "address": null,
    "location": null,
    "count": 0,
    "rend_date": null,
    "frequency": 2,
    "interval": 2,
    "specifier": "D=0TH",
    "trigger_interval": -600,
    "eseconds": 1751553000,
    "ectime": "2025-07-03 10:30:00 +0000",
    "edate": "today",
    "sseconds": 1751551200,
    "sctime": "2025-07-03 10:00:00 +0000",
    "sdate": "today"
  }
]

Temporary fix

It works great to me, it was generated by AI.

CURRENT_UTC_UNIX_TIMESTAMP=$(date -u +%s)
icalPal -o json -c eventsNow | \
jq --argjson now "$CURRENT_UTC_UNIX_TIMESTAMP" -r '[.[] | select(.sseconds <= $now and .eseconds >= $now)]'

[ajrosen]

I'm glad you have something that's working for you! But the solution doesn't make any sense to me.

icalPal uses the sdate/edate fields to see if an event occurs during the start/end window, or is occurring now (for the eventsNow command).

The fields sseconds/eseconds, sctime/ectime, and sdate/edate all have the same value; they're just different variable types. So having jq compare sseconds/eseconds against $now is doing the same thing as icalPal comparing sdate/edate.

[MynockSpit]

Possibly related to this, I found a couple of weird cases where sctime (and ectime) have the wrong timezone (and thus the wrong time):

  "eseconds": 1751310000,
  "ectime": "2025-10-16 15:00:00 +0000",
  "edate": "today",
  "sseconds": 1751308200,
  "sctime": "2025-10-16 14:30:00 +0000",
  "sdate": "today",
  "rseconds": 1767157199,
  "rctime": "2025-12-30 21:59:59 -0700",
  "rdate": "Dec 30, 2025"

> new Date(1751308200*1000)
2025-06-30T18:30:00.000Z

The default output also shows the wrong time:

    today at 2:30 PM - 3:00 PM

Versus in this case, it has the correct timezone.

  "eseconds": 1760650200,
  "ectime": "2025-10-16 15:30:00 -0600",
  "edate": "today",
  "sseconds": 1760646600,
  "sctime": "2025-10-16 14:30:00 -0600",
  "sdate": "today"

> new Date(1760646600*1000)
2025-10-16T20:30:00.000Z

The first case is a recurring meeting, so perhaps that's related?

[ajrosen]

It is related to recurring events. The "r" variables hold the "recurrence end date". And when finding the next occurrence of an event, sctime/ectime get updated along with scdate/ecdate.

However, when that happens, I am setting the timezone for sctime/ectime to +00:00, regardless of what it was. It shouldn't do that. So you've uncovered a bug. Thanks!