cal/major-domo-v2
1
0
Fork 0
Code Issues 6 Pull Requests 2 Actions Packages Projects Releases Wiki Activity

fix: UTC timezone conversion breaking time-based features #43

New Issue
Closed
opened 2026-02-22 03:34:48 +00:00 by cal · 1 comment
cal commented 2026-02-22 03:34:48 +00:00
Owner
Copy Link

Problem

After the recent update, all time zones were set to UTC. The server is physically located in America/Chicago and was previously using naive datetime objects that honored the local machine time (CST/CDT).

Now that we've explicitly set the timezone to UTC, the system is showing times that are approximately 6 hours off from expected local times.

Impact

  • Time-based features are displaying incorrect times
  • Scheduled tasks may be running at the wrong times
  • User-facing timestamps are confusing/incorrect

Expected Behavior

Times should be stored in UTC internally but displayed in America/Chicago (Central Time) for user-facing features.

Proposed Solution

  1. Keep UTC for internal storage (database, logging)
  2. Convert to America/Chicago for user-facing displays
  3. Review all datetime objects to ensure proper timezone handling
  4. Update any scheduled tasks to account for the timezone difference

Technical Details

  • Server timezone: America/Chicago (UTC-6 in winter, UTC-5 in summer)
  • Previous behavior: Naive datetime objects honored local machine time
  • Current behavior: Explicit UTC causing ~6 hour offset
## Problem After the recent update, all time zones were set to UTC. The server is physically located in America/Chicago and was previously using naive datetime objects that honored the local machine time (CST/CDT). Now that we've explicitly set the timezone to UTC, the system is showing times that are approximately 6 hours off from expected local times. ## Impact - Time-based features are displaying incorrect times - Scheduled tasks may be running at the wrong times - User-facing timestamps are confusing/incorrect ## Expected Behavior Times should be stored in UTC internally but displayed in America/Chicago (Central Time) for user-facing features. ## Proposed Solution 1. Keep UTC for internal storage (database, logging) 2. Convert to America/Chicago for user-facing displays 3. Review all datetime objects to ensure proper timezone handling 4. Update any scheduled tasks to account for the timezone difference ## Technical Details - Server timezone: America/Chicago (UTC-6 in winter, UTC-5 in summer) - Previous behavior: Naive datetime objects honored local machine time - Current behavior: Explicit UTC causing ~6 hour offset
cal commented 2026-02-22 04:39:21 +00:00
Author
Owner
Copy Link

Solution Implemented

Root Cause

The transaction freeze/thaw task was checking for midnight in UTC instead of America/Chicago timezone. This caused the task to run 6 hours early:

  • Friday 6:00 PM CST = Saturday 00:00 UTC → Thaw ran 6 hours early
  • Sunday 6:00 PM CST = Monday 00:00 UTC → Freeze ran 6 hours early

Changes Made

1. New Timezone Utility Module (utils/timezone.py)

  • now_in_chicago() - Get current time in Chicago timezone
  • utc_to_chicago() - Convert UTC to Chicago time
  • chicago_to_utc() - Convert Chicago to UTC time
  • format_discord_timestamp() - Format datetimes for Discord (shows in user's local timezone)
  • Full test coverage in tests/test_utils_timezone.py

2. Fixed Critical Scheduling Bug (tasks/transaction_freeze.py)

  • Line 328-339: Changed from datetime.now(UTC) to now_in_chicago() for schedule checks
  • Line 362: Saturday check now uses Chicago time instead of UTC
  • Line 390: Error notifications now use Discord timestamp formatting
  • Line 1098: Thaw reports now use Discord timestamp formatting

3. Fixed User-Facing Time Displays

  • utils/logging.py:35 - Fixed missing UTC timezone in log timestamps
  • views/transaction_embed.py:482 - Transaction footers now use Discord timestamps
  • views/trade_embed.py:802 - Trade footers now use Discord timestamps
  • commands/admin/management.py - All 8 admin timestamps use Discord formatting
  • commands/admin/users.py - All 5 user management timestamps use Discord formatting

All timestamps now automatically display in each user's local timezone via Discord's native formatting.

Testing

✅ All 14 timezone utility tests passing
✅ Syntax validation passed for all modified files
✅ Import validation successful

Next Steps

  1. Review and test on development/staging
  2. Monitor first freeze/thaw cycle after deployment to confirm correct timing
  3. Deploy to production

Expected behavior after fix:

  • Freeze begins: Monday 00:00 America/Chicago (was running Sunday 6 PM)
  • Thaw runs: Saturday 00:00 America/Chicago (was running Friday 6 PM)
## Solution Implemented ### Root Cause The transaction freeze/thaw task was checking for midnight **in UTC** instead of **America/Chicago** timezone. This caused the task to run 6 hours early: - **Friday 6:00 PM CST** = **Saturday 00:00 UTC** → Thaw ran 6 hours early - **Sunday 6:00 PM CST** = **Monday 00:00 UTC** → Freeze ran 6 hours early ### Changes Made #### 1. New Timezone Utility Module (`utils/timezone.py`) - `now_in_chicago()` - Get current time in Chicago timezone - `utc_to_chicago()` - Convert UTC to Chicago time - `chicago_to_utc()` - Convert Chicago to UTC time - `format_discord_timestamp()` - Format datetimes for Discord (shows in user's local timezone) - Full test coverage in `tests/test_utils_timezone.py` #### 2. Fixed Critical Scheduling Bug (`tasks/transaction_freeze.py`) - **Line 328-339**: Changed from `datetime.now(UTC)` to `now_in_chicago()` for schedule checks - **Line 362**: Saturday check now uses Chicago time instead of UTC - **Line 390**: Error notifications now use Discord timestamp formatting - **Line 1098**: Thaw reports now use Discord timestamp formatting #### 3. Fixed User-Facing Time Displays - `utils/logging.py:35` - Fixed missing UTC timezone in log timestamps - `views/transaction_embed.py:482` - Transaction footers now use Discord timestamps - `views/trade_embed.py:802` - Trade footers now use Discord timestamps - `commands/admin/management.py` - All 8 admin timestamps use Discord formatting - `commands/admin/users.py` - All 5 user management timestamps use Discord formatting All timestamps now automatically display in each user's local timezone via Discord's native formatting. ### Testing ✅ All 14 timezone utility tests passing ✅ Syntax validation passed for all modified files ✅ Import validation successful ### Next Steps 1. Review and test on development/staging 2. Monitor first freeze/thaw cycle after deployment to confirm correct timing 3. Deploy to production **Expected behavior after fix:** - Freeze begins: Monday 00:00 America/Chicago (was running Sunday 6 PM) - Thaw runs: Saturday 00:00 America/Chicago (was running Friday 6 PM)
cal closed this issue 2026-02-22 22:16:55 +00:00
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels   
ai-changes-requested

   
ai-pr-opened

   
ai-reviewed

   
ai-reviewing

   
ai-working

   
in-next-release

Fix included in the next-release branch, pending merge to main

  
status/in-progress

Work is actively in progress

  
status/pr-open

A pull request has been opened for this issue

No Label
ai-changes-requested
ai-pr-opened
ai-reviewed
ai-reviewing
ai-working
in-next-release
status/in-progress
status/pr-open
Milestone
Clear milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
No Assignees
1 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: cal/major-domo-v2#43
No description provided.
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?