Page MenuHomePhabricator

Fix an issue where internal Calendar DateTimes would not be correctly set to all-day
ClosedPublic

Authored by epriestley on Nov 28 2016, 4:53 PM.
Tags
None
Referenced Files
F18785830: D16954.id40804.diff
Tue, Oct 14, 12:39 PM
F18771657: D16954.diff
Wed, Oct 8, 8:54 PM
F18620698: D16954.id40803.diff
Sep 15 2025, 6:04 AM
F18238982: D16954.id.diff
Aug 20 2025, 11:06 PM
F18233701: D16954.id40804.diff
Aug 20 2025, 4:58 PM
F18232614: D16954.id40803.diff
Aug 20 2025, 3:49 PM
F18232259: D16954.id.diff
Aug 20 2025, 3:24 PM
F18218809: D16954.diff
Aug 19 2025, 10:36 AM
Subscribers
None

Details

Summary

Ref T11816. I don't really know what happened here, maybe I rewrote and broke this at the last second?

In most cases, we directly respect the isAllDay flag on the event, so the internal date state doesn't matter too much.

However, in the case of mail notifications, the raw internal state is relevant. This should fix mail notifications for all-day events.

(I might still turn them off since I'm not sure they're too useful, but it's good to have them working.)

Test Plan
  • Created a new all-day event, verified database values wrote correctly.
  • Ran bin/calendar notify --trace, verified it picked up an all-day event tomorrow with a large enough --minutes value.

Diff Detail

Repository
rP Phabricator
Lint
Lint Not Applicable
Unit
Tests Not Applicable

Event Timeline

epriestley retitled this revision from to Fix an issue where internal Calendar DateTimes would not be correctly set to all-day.
epriestley updated this object.
epriestley edited the test plan for this revision. (Show Details)
epriestley added a reviewer: chad.
chad edited edge metadata.
This revision is now accepted and ready to land.Nov 28 2016, 4:53 PM
This revision was automatically updated to reflect the committed changes.