docs(calendar): warn against container-default timezone in time conversion - #2104
Conversation
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (3)
🚧 Files skipped from review as they are similar to previous changes (3)
📝 WalkthroughWalkthroughCalendar documentation now requires explicit timezone offsets for command timestamps and explicit target timezones when converting Unix seconds, including warnings against relying on container defaults. ChangesCalendar timezone guidance
Estimated code review effort: 1 (Trivial) | ~5 minutes Suggested reviewers: 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
🚀 PR Preview Install Guide🧰 CLI updatenpm i -g https://pkg.pr.new/larksuite/cli/@larksuite/cli@68ec21e63bd89169e8cfe2bf0d80b5e7d935df24🧩 Skill updatenpx skills add larksuite/cli#docs/calendar-timezone-guidance -y -g |
…rsion Agents dropping to the raw `calendar events create/patch` API must convert wall-clock time to Unix timestamps themselves. In UTC containers this silently yields an 8-hour offset. Require explicit ISO 8601 offsets on +create/+update --start/--end, and warn that raw-API timestamp conversion must specify the target timezone instead of relying on the container default.
515e82e to
68ec21e
Compare
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #2104 +/- ##
==========================================
+ Coverage 75.16% 75.19% +0.03%
==========================================
Files 912 914 +2
Lines 96475 96783 +308
==========================================
+ Hits 72517 72778 +261
- Misses 18381 18407 +26
- Partials 5577 5598 +21 ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
Summary
Calendar events created via the raw
calendar events create/patchAPI showed a consistent 8-hour offset. When a shortcut cannot express a field (e.g.location, customreminders), agents drop down to the raw API, which takes Unix-second timestamps. Agents then convert wall-clock time themselves, and in UTC containers this silently produces an 8-hour offset (e.g. Beijing 11:00 becomes 19:00). This PR strengthens the skill docs to steer agents onto the timezone-safe path and warn about the raw-API conversion pitfall. Docs-only, no code changes.Changes
SKILL.md: fold a timezone warning into the existing mandatory time-conversion note — conversion must not rely on the container default timezone (often UTC → 8-hour offset) and must specify the target timezone explicitly.references/lark-calendar-create.md: require--start/--endto carry an explicit timezone offset (offsets omitted are parsed in the process timezone and drift); add the same raw-API timestamp-conversion warning.references/lark-calendar-update.md: apply the identical--start/--endand raw-API timestamp warnings for consistency.Test Plan
Related Issues
Summary by CodeRabbit
calendar +createdocs to require ISO 8601 timestamps with explicit timezone offsets for--startand--end, noting missing offsets may shift times.calendar event.attendees createand full APIcalendar +updateusage notes to require explicit target timezone handling when converting Unix seconds.