Calendar Cycle Calculation Logic closes #276 #284
No reviewers
Labels
No labels
bug
duplicate
enhancement
help wanted
high priority
invalid
L
low priority
M
medium priority
needs refinement
question
S
UX research
wontfix
No milestone
No project
No assignees
2 participants
Notifications
Due date
No due date set.
Blocks
Depends on
#290 Cycle Generation System closes #277
local-it/mitgliederverwaltung
#283 Membership Fee - Database Schema & Ash Domain Foundation closes #275
local-it/mitgliederverwaltung
Reference: local-it/mitgliederverwaltung#284
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "feature/276_cycle_calculation"
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?
Description of the implemented changes
The changes were:
Definition of Done
Code Quality
Accessibility
Testing
WIP: Calendar Cycle Calculation Logic closes #276to Calendar Cycle Calculation Logic closes #276ecddf55331toaa7e5a7d38aa7e5a7d38toa7285915e6looks good to me :)
@ -0,0 +10,4 @@The time-dependent functions (`current_cycle?/3`, `last_completed_cycle?/3`)depend on a date parameter for testability. Their 2-argument variants(`current_cycle?/2`, `last_completed_cycle?/2`) use `Date.utc_today()` andIf our meaning of “today” is Europe/Berlin (or any non-UTC TZ), we can be wrong for a window around midnight.
We could explicitly define the business clock as UTC (and document it), or centralize “today” behind a project helper (e.g. Mv.Time.today/0) that uses a configured timezone.
I think this could be a part of a new issues, to set a timezone in the global settings
@ -0,0 +50,4 @@## Parameters- `date` - Ignored in this 3-argument version (kept for API consistency)why for API consistency?
Because all other cycle function use the current date as first argument for testing the functions. This is just kept to have consistency between the other functions.