-
Notifications
You must be signed in to change notification settings - Fork 0
fix: modify date parsing logic #22
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Pull request overview
This pull request improves date formatting consistency in customer billing email tasks by introducing a shared date format constant and updating datetime handling. While the intent is good, the implementation introduces inconsistencies with established codebase patterns for timezone-aware datetime creation.
- Adds
BRAZE_DATE_DD_MM_YYYYconstant for consistent "DD Month YYYY" date formatting - Updates date formatting in trial end/subscription start and payment receipt emails
- Changes datetime parsing from deprecated
utcfromtimestamp()tofromtimestamp()with timezone awareness
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated 3 comments.
| File | Description |
|---|---|
| enterprise_access/apps/customer_billing/constants.py | Adds new BRAZE_DATE_DD_MM_YYYY constant for standardized date formatting across email templates |
| enterprise_access/apps/customer_billing/tasks.py | Updates datetime imports and modifies date parsing in two email tasks to use timezone-aware UTC datetimes and the new format constant |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| start_str = format_datetime_obj(datetime.fromtimestamp(period_start, tz=tz.utc), BRAZE_DATE_DD_MM_YYYY) | ||
| end_str = format_datetime_obj(datetime.fromtimestamp(period_end, tz=tz.utc), BRAZE_DATE_DD_MM_YYYY) |
Copilot
AI
Dec 18, 2025
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The timezone handling here is inconsistent with the established pattern in this codebase. Throughout this file (lines 142, 143, 213, 339), the codebase uses timezone.make_aware(datetime.fromtimestamp()) to create timezone-aware datetime objects. The new approach using datetime.fromtimestamp(period_start, tz=tz.utc) is functionally equivalent but breaks this consistent pattern.
Additionally, the import alias timezone as tz for the standard library's timezone conflicts with the existing import of Django's timezone utility on line 11, which is used throughout this file for timezone.make_aware(). This makes the code harder to maintain and understand.
For consistency with the rest of the codebase, consider using the established pattern instead.
7456d74 to
7727602
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Pull request overview
Copilot reviewed 2 out of 2 changed files in this pull request and generated no new comments.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Pull request overview
Copilot reviewed 5 out of 5 changed files in this pull request and generated 4 comments.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Pull request overview
Copilot reviewed 5 out of 5 changed files in this pull request and generated 2 comments.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Pull request overview
Copilot reviewed 6 out of 6 changed files in this pull request and generated 4 comments.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
8206664 to
2212648
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Pull request overview
Copilot reviewed 6 out of 7 changed files in this pull request and generated 6 comments.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
ENT-11296: Change the trial cancellation email to trigger when the user cancels their subscription in Stripe (cancel_at set) rather than when the subscription status changes to canceled at the end of the 14-day trial. This provides immediate feedback to users when they cancel. Adds subscription_cancel_at field to StripeEventSummary model to track scheduled cancellations. Includes duplicate prevention to ensure users only receive one cancellation email. The status change trigger remains as a fallback for edge cases. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Pull request overview
Copilot reviewed 7 out of 8 changed files in this pull request and generated 1 comment.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
5cda7c5 to
aa0635f
Compare
aa0635f to
1e031ce
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Pull request overview
Copilot reviewed 7 out of 8 changed files in this pull request and generated 1 comment.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
1e031ce to
d598f2e
Compare
d598f2e to
a189654
Compare
a189654 to
5a76e7b
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Pull request overview
Copilot reviewed 7 out of 8 changed files in this pull request and generated 2 comments.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Pull request overview
Copilot reviewed 7 out of 8 changed files in this pull request and generated 2 comments.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| def test_datetime_from_timestamp_has_expected_components(self): | ||
| """ | ||
| Validate that datetime_from_timestamp returns the correct *local-date* | ||
| representation for the given timestamp. | ||
| """ |
Copilot
AI
Jan 7, 2026
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This test comment mentions "local-date representation" which suggests awareness of the timezone issue. However, testing against the same flawed implementation (computing expected using the same method) means the test validates consistency with the bug rather than correctness. The test should instead use a known timestamp and verify against the expected UTC datetime value, independent of server timezone configuration.
| def test_datetime_from_timestamp_uses_current_timezone(self): | ||
| """ | ||
| datetime_from_timestamp should attach the current Django timezone | ||
| (make_aware default behavior). | ||
| """ | ||
| ts = 1767285545 | ||
|
|
||
| dt = datetime_from_timestamp(ts) | ||
|
|
||
| self.assertEqual(dt.tzinfo, pytz.UTC) |
Copilot
AI
Jan 7, 2026
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This test has a misleading docstring. It states "datetime_from_timestamp should attach the current Django timezone (make_aware default behavior)" but then asserts dt.tzinfo == pytz.UTC. The test name also says "uses_current_timezone" which conflicts with the assertion checking for UTC.
The docstring suggests the function should use Django's current timezone setting, but the implementation explicitly passes timezone=pytz.UTC to make_aware, which overrides the current timezone. The test should clarify that it expects UTC timezone specifically, not the "current" timezone.
Description:
This pull request refactors how Unix timestamps are converted to timezone-aware datetime objects across the customer billing app. The main change is the introduction of a new utility function,
datetime_from_timestamp, which centralizes and standardizes this conversion. The pull request also updates all relevant usages to use this new function, adds comprehensive unit tests for it, and introduces a new date format constant for consistency in formatting.Refactoring and Code Consistency:
datetime_from_timestampinutils.pyto standardize conversion of Unix timestamps to timezone-aware datetimes, replacing scattered implementations throughout the codebase.models.pyandtasks.pyto use the newdatetime_from_timestampfunction, improving code maintainability and consistency. [1] [2] [3] [4] [5] [6] [7]Testing:
test_utils.pyto verify correctness, timezone awareness, and expected behavior ofdatetime_from_timestamp.Formatting Improvements:
BRAZE_DATE_DD_MM_YYYYinconstants.pyand updated formatting intasks.pyto use this constant for consistency in date representations. [1] [2] [3]Code Cleanup:
_datetime_from_timestampfunction frommodels.py. [1] [2]Jira:
ENT-XXXX
Merge checklist:
./manage.py makemigrationshas been runPost merge: