Time and Date Bugs

An event's start time is stored correctly in UTC but displayed to the user without timezone conversion. The frontend renders the raw UTC hour directly, so a user in America/New_York (UTC−5) who expects to see 3:00 PM EST instead sees 8:00 PM — the unmodified UTC value. This is a UTC↔local conversion error: the stored timestamp is correct, but the display layer never applies the user's timezone offset.

A 30-day subscription purchased on 2024-11-01 should grant access through the end of 2024-11-30. The expiry datetime is stored as 2024-11-30T00:00:00Z — the start of the last valid day in UTC — rather than 2024-12-01T00:00:00Z (the exclusive upper bound). The validity check NOW() >= expiry_at fires at midnight UTC on 2024-11-30, which is 7:00 PM EST on 2024-11-29 for a user in America/New_York (UTC−5). The subscription appears expired on November 29, one calendar day earlier than the user was told. This is a datetime boundary error: the exclusive expiry bound is set to start_of_day(last_valid_day) instead of start_of_day(last_valid_day + 1).

A 24-hour trial subscription purchased at midnight on 2024-03-10 in America/New_York — the US spring-forward day — should grant exactly 24 hours of access. The server computes the expiry using local calendar arithmetic: midnight March 10 EST plus one local day equals midnight March 11 EDT, which is 2024-03-11T04:00:00Z. Because the spring-forward transition makes March 10 only 23 UTC hours long, the stored expiry is 23 hours from the purchase timestamp rather than the expected 24. The subscription expires one hour earlier than the user's stated trial duration.