GeezerVison

Tableau Server references a schedule by id inside a <subscription>:

    <schedule id="cfb2..." name="Weekday mornings"/>

Tableau Cloud inlines the schedule instead -- no id attribute, but
a `frequency`, `nextRunAt` and a nested `<frequencyDetails>`:

    <schedule frequency="Daily" nextRunAt="2026-08-29T16:55:00-0700">
      <frequencyDetails start="16:55:00" end="16:55:00">
        <intervals>
          <interval hours="24"/>
          <interval weekDay="Saturday"/>
        </intervals>
      </frequencyDetails>
    </schedule>

Previously `SubscriptionItem` only pulled `id`/`name` off `<schedule>`,
so on Cloud every subscription came back with `schedule_id == None`
and no structured way to see what the API sent. Client code filtering
`[s for s in subs if s.schedule_id == target]` silently returned `[]`
on Cloud. This is the bug described in issue #1627.

Model changes:

* `SubscriptionItem` now populates a `schedule: ScheduleItem` attribute
  for both shapes. On Server, `schedule.id`/`.name` are set (and
  `schedule_id` remains populated for back-compat). On Cloud,
  `schedule.frequency`, `schedule.next_run_at`, and
  `schedule.interval_item` are set. `schedule_id` is `None` on Cloud --
  the API does not send one, unavoidable. Docstring calls out the
  Cloud-vs-Server discriminator and warns callers who filter by
  `schedule_id`. Fixes a latent bug where the previous Cloud branch
  assigned a list (return of `ScheduleItem.from_element`) to
  `sub.schedule` instead of a single item.
* `ScheduleItem` gains a `frequency` property. The XML attribute was
  already being read to select the interval type but was discarded;
  now it's exposed so callers can distinguish the Cloud shape without
  reaching into the interval object. The class `Attributes` docstring
  is rewritten to cover every public property and to note that only
  `frequency` / `next_run_at` / `interval_item` are populated when the
  item comes from an inlined Cloud subscription schedule.
* `_parse_interval_item` is defensive against malformed Cloud data:
  a `<frequencyDetails>` without a `start` attribute no longer crashes
  on `strptime(None, ...)`, and an out-of-range `<interval hours="3"/>`
  (or unknown weekDay / monthDay) no longer raises `ValueError` out of
  `IntervalItem` and poisons sibling schedules in the same page. Bad
  data degrades to `interval_item = None` with a warning log.

Datetime plumbing:

* `parse_datetime` learns the Tableau Cloud `%Y-%m-%dT%H:%M:%S%z` form
  (e.g. `2026-08-29T16:55:00-0700`) in addition to the Server `...Z`
  form. Unparseable input still returns `None` on the read path
  (preserving the pre-change contract that a malformed server-side
  date cannot crash a page-through of unrelated data).
* `property_is_datetime` now raises `ValueError` when `parse_datetime`
  returns `None` for a non-empty str value. Bad *user* input is
  surfaced at the assignment site instead of silently nulling the
  attribute.
* `TABLEAU_CLOUD_DATE_FORMAT` is public, matching the existing
  `TABLEAU_DATE_FORMAT`.

Tests:

* New `test/assets/subscription_get_cloud.xml` mirroring the shape
  observed on `stage-dp1` (API 3.29) and matching parse tests for
  both Cloud and Server shapes.
* Three edge-case Cloud fixtures + tests: no `<frequencyDetails>`,
  empty `<intervals/>`, out-of-set `<interval hours="3"/>`.
* Existing subscription tests extended to cover sub 2 and
  `get_subscription_by_id`.
* New `test/test_datetime_helpers.py` with direct coverage of
  `parse_datetime` (None / "" / garbage / Server / Cloud / colon-offset
  / microseconds) and `property_is_datetime` (valid / bad / non-str).
* `test/test_schedule.py::test_get` asserts the new
  `ScheduleItem.frequency` property on the standard /schedules endpoint.

Refs: #1627

Co-Authored-By: Claude Opus 4.7 (1M context) <[email protected]>

Copilot AI left a comment

- Widen SubscriptionItem.__init__.schedule_id to Optional[str]; Cloud
  inline <schedule> elements have no id and _parse_element passes None
- Rewrite property_is_datetime docstring: parse_datetime accepts both
  trailing-Z and explicit-offset forms; setter now raises ValueError on
  unparseable strings
- Correct the SubscriptionItem docstring's Cloud-vs-Server discriminator:
  the reliable check is (schedule is not None and schedule.id is None),
  not (interval_item is not None) - Cloud can omit <frequencyDetails>

Co-Authored-By: Claude Opus 4.7 (1M context) <[email protected]>

Previously parse_datetime returned Cloud datetimes with the wire's offset
attached (e.g. tzinfo == timezone(-7:00)), so the same field had different
tzinfo depending on cell type. Callers using .strftime("...Z") got wrong
output on Cloud; callers comparing to a UTC constant with == got False even
on the same instant.

Convert the Cloud branch's strptime result via .astimezone(utc), so every
next_run_at returned from TSC is uniformly tzinfo == utc regardless of
whether the wire used trailing Z or an explicit numeric offset. Callers
who want the site's local zone can inspect the wire elsewhere (schedule
name, admin API); nobody was relying on the offset today.

Co-Authored-By: Claude Opus 4.7 (1M context) <[email protected]>

Cosmetic — reads cleaner as a single literal.

Co-Authored-By: Claude Opus 4.7 (1M context) <[email protected]>

Copilot AI left a comment

- ScheduleItem._parse_common_tags discarded the frequency returned by
  _parse_element, so a schedule returned from schedules.update() had
  frequency None. Capture it and pass it to _set_values, as from_element does.
- _parse_interval_item left hourly hours="N" as a string, so an invalid
  value such as 3 passed HourlyInterval validation instead of degrading to
  interval_item None. Convert with float(), matching the Daily branch.
- Add tests for <frequencyDetails> without start and for hourly hours
  validation; update test_create_hourly to expect numeric intervals.

Co-Authored-By: Claude Code <[email protected]>

jacalata left a comment

jacalata left a comment

jacalata left a comment

jacalata left a comment

Copilot AI left a comment

Copilot AI left a comment