ChenKaiLiuG/life_generators
1
0
Fork 0
Code Issues 7 Pull Requests Actions Packages Projects Releases 1 Wiki Activity

feat: add support for cyclical dates in special events to avoid yearly updates #45

Merged
tobiichi3227 merged 11 commits from feat/cyclical-special-event into main 2024-12-12 14:48:21 +00:00
Conversation 11 Commits 11 Files Changed 6 +1081 -210
tobiichi3227 commented 2024-12-03 15:10:55 +00:00 (Migrated from github.com)
Copy Link

Add suport for cyclical date for special event.
Allow users to avoid updating the same special event dates every year.
Enhance the robustness of special event data parsing.

Add suport for cyclical date for special event. Allow users to avoid updating the same special event dates every year. Enhance the robustness of special event data parsing.
lifeadventurer (Migrated from github.com) requested changes 2024-12-03 15:52:03 +00:00
lifeadventurer (Migrated from github.com) left a comment
Copy Link

Wish you could separate special.json into three files for better organization:

  1. static_special.json for events with fixed dates.
  2. cyclical_special.json for recurring events (e.g., holidays like Thanksgiving and Mother's Day).
  3. custom_special.json for user-defined or custom events.

This separation would improve clarity and make managing different event types more efficient. Let me know what you think.

Wish you could separate `special.json` into three files for better organization: 1. `static_special.json` for events with fixed dates. 2. `cyclical_special.json` for recurring events (e.g., holidays like Thanksgiving and Mother's Day). 3. `custom_special.json` for user-defined or custom events. This separation would improve clarity and make managing different event types more efficient. Let me know what you think.
fortune_generator/js/fortune.js
lifeadventurer (Migrated from github.com) commented 2024-12-03 15:46:27 +00:00
Copy Link
  1. Code Duplication: Repeated checks (e.g., isNaN, range validation) could be extracted into helper functions for cleaner code. 
    function validateNumber(value, min, max, fieldName, event) {
    value = parseInt(value);
    if (isNaN(value) || value < min || value > max) {
        console.warn(`illegal event: ${fieldName} should be between ${min} and ${max}`, event);
        return null;
    }
    return value;
}
  2. Readability: The nested else and validation blocks make the code harder to read. Refactor to flatten the structure where possible.
  3. Default Behavior: If both week/weekday and date are missing, consider whether a more graceful fallback (or an error throw) is appropriate rather than just logging and returning -1.
  4. Edge Cases: Ensure that edge cases like invalid months (eventMonth - 1 for zero-based indexing) or dates exceeding month limits (e.g., 31 in February) are handled properly.
1. **Code Duplication**: Repeated checks (e.g., `isNaN`, range validation) could be extracted into helper functions for cleaner code. ```js function validateNumber(value, min, max, fieldName, event) { value = parseInt(value); if (isNaN(value) || value < min || value > max) { console.warn(`illegal event: ${fieldName} should be between ${min} and ${max}`, event); return null; } return value; } ``` 2. **Readability**: The nested `else` and validation blocks make the code harder to read. Refactor to flatten the structure where possible. 3. **Default Behavior**: If both `week`/`weekday` and `date` are missing, consider whether a more graceful fallback (or an error throw) is appropriate rather than just logging and returning `-1`. 4. **Edge Cases**: Ensure that edge cases like invalid months (`eventMonth - 1` for zero-based indexing) or dates exceeding month limits (e.g., `31` in February) are handled properly.
fortune_generator/js/fortune.js
lifeadventurer (Migrated from github.com) commented 2024-12-03 15:22:17 +00:00
Copy Link

It looks like the line for splitting and parsing the IP address is commented out, and a hardcoded value is used instead. Please remove this line.

It looks like the line for splitting and parsing the IP address is commented out, and a hardcoded value is used instead. Please remove this line.
fortune_generator/json/special.json
@@ -8,3 +9,4 @@
},
"status_index": "0",
"goodFortunes": {
"l_1_event": "家人團聚",
lifeadventurer (Migrated from github.com) commented 2024-12-03 15:39:27 +00:00
Copy Link

感恩節 is celebrated on the fourth Thursday of November.

感恩節 is celebrated on the fourth Thursday of November.
fortune_generator/json/special.json
@@ -133,68 +141,12 @@
"r_2_desc": ""
}
lifeadventurer (Migrated from github.com) commented 2024-12-03 15:30:01 +00:00
Copy Link

Please remove the following three events.

Please remove the following three events.
fortune_generator/json/special.json
lifeadventurer (Migrated from github.com) commented 2024-12-03 15:39:12 +00:00
Copy Link

感恩節 is celebrated on the fourth Thursday of November.

感恩節 is celebrated on the fourth Thursday of November.
fortune_generator/json/special.json
lifeadventurer (Migrated from github.com) commented 2024-12-03 15:37:33 +00:00
Copy Link

中秋節 (Mid-Autumn Festival) does not fall on the same day every year as it follows the lunar calendar.

中秋節 (Mid-Autumn Festival) does not fall on the same day every year as it follows the lunar calendar.
tobiichi3227 commented 2024-12-09 08:01:10 +00:00 (Migrated from github.com)
Copy Link

Wish you could separate special.json into three files for better organization:

  1. static_special.json for events with fixed dates.
  2. cyclical_special.json for recurring events (e.g., holidays like Thanksgiving and Mother's Day).
  3. custom_special.json for user-defined or custom events.

This separation would improve clarity and make managing different event types more efficient. Let me know what you think.

Should user-defined events also be divided into fixed dates and recurring dates?

> Wish you could separate `special.json` into three files for better organization: > > 1. `static_special.json` for events with fixed dates. > 2. `cyclical_special.json` for recurring events (e.g., holidays like Thanksgiving and Mother's Day). > 3. `custom_special.json` for user-defined or custom events. > > This separation would improve clarity and make managing different event types more efficient. Let me know what you think. Should user-defined events also be divided into fixed dates and recurring dates?
lifeadventurer commented 2024-12-09 08:13:40 +00:00 (Migrated from github.com)
Copy Link

Wish you could separate special.json into three files for better organization:

  1. static_special.json for events with fixed dates.
  2. cyclical_special.json for recurring events (e.g., holidays like Thanksgiving and Mother's Day).
  3. custom_special.json for user-defined or custom events.

This separation would improve clarity and make managing different event types more efficient. Let me know what you think.

Should user-defined events also be divided into fixed dates and recurring dates?

Yes, user-defined (custom) events should also be divided into fixed dates and recurring dates. By "custom," I mean events that don't fall into the first two categories (static or cyclical). Separating them ensures clarity and better organization across all event types.

> > Wish you could separate `special.json` into three files for better organization: > > > > 1. `static_special.json` for events with fixed dates. > > 2. `cyclical_special.json` for recurring events (e.g., holidays like Thanksgiving and Mother's Day). > > 3. `custom_special.json` for user-defined or custom events. > > > > This separation would improve clarity and make managing different event types more efficient. Let me know what you think. > > Should user-defined events also be divided into fixed dates and recurring dates? Yes, user-defined (custom) events should also be divided into fixed dates and recurring dates. By "custom," I mean events that don't fall into the first two categories (static or cyclical). Separating them ensures clarity and better organization across all event types.
lifeadventurer commented 2024-12-12 10:10:43 +00:00 (Migrated from github.com)
Copy Link

Hi there,

I'm a bit confused by the current implementation. In our previous discussion about separating special.json, we agreed on a clear and straightforward organization:

  1. static_special.json for events with fixed dates
  2. cyclical_special.json for recurring events
  3. custom_special.json for user-defined events

However, your current commit introduces four different JSON files:

  • custom_static_special.json
  • custom_cyclical_special.json
  • default_static_special.json
  • default_cyclical_special.json

This approach raises several questions:

  • Why are you introducing the distinction between "custom" and "default" events?
  • If an event is static or cyclical, why wouldn't it simply go into the static_special.json or cyclical_special.json respectively?
  • What defines a "default" event versus a "custom" event?
  • If a special event doesn't fit into static or cyclical categories, how would it be classified?

The original proposal was to create a clear, simple organizational structure. Your current implementation seems to add unnecessary complexity without a clear rationale.

Could you explain the reasoning behind this approach? I'm concerned that this might make the code harder to understand and maintain.

Looking forward to your explanation.

Hi there, I'm a bit confused by the current implementation. In our previous discussion about separating `special.json`, we agreed on a clear and straightforward organization: 1. `static_special.json` for events with fixed dates 2. `cyclical_special.json` for recurring events 3. `custom_special.json` for user-defined events However, your current commit introduces four different JSON files: - `custom_static_special.json` - `custom_cyclical_special.json` - `default_static_special.json` - `default_cyclical_special.json` This approach raises several questions: - Why are you introducing the distinction between "custom" and "default" events? - If an event is static or cyclical, why wouldn't it simply go into the `static_special.json` or `cyclical_special.json` respectively? - What defines a "default" event versus a "custom" event? - If a special event doesn't fit into static or cyclical categories, how would it be classified? The original proposal was to create a clear, simple organizational structure. Your current implementation seems to add unnecessary complexity without a clear rationale. Could you explain the reasoning behind this approach? I'm concerned that this might make the code harder to understand and maintain. Looking forward to your explanation.
tobiichi3227 commented 2024-12-12 11:53:17 +00:00 (Migrated from github.com)
Copy Link

User-defined events only contain static date or recurring date.
Why not simply place the user-defined events in static_special.json and cyclical_special.json?
The current custom_special.json is the same as the original special.json, containing both types.

User-defined events only contain static date or recurring date. Why not simply place the user-defined events in `static_special.json` and `cyclical_special.json`? The current `custom_special.json` is the same as the original `special.json`, containing both types.
lifeadventurer commented 2024-12-12 13:39:49 +00:00 (Migrated from github.com)
Copy Link

Let me clarify the distinctions between these event types:

  1. Static Events (Fixed Date):

    • Occur on the exact same date every year
    • Examples: Christmas (always December 25th)
    • These events have a consistent, fixed date that doesn't change from year to year

  2. Cyclical Events (Variable Date):

    • Occur annually, but on a varying date based on a pattern
    • Examples:
      • Thanksgiving (fourth Thursday of November)
      • Mother's Day (second Sunday in May)
      • These events happen every year, but the exact date shifts based on a specific rule

  3. Custom Special Events (Non-Recurring):

    • One-time or irregular events
    • These are different from both static and cyclical events because they don't follow a predictable yearly pattern

The key difference is the recurrence pattern. Static and cyclical events will happen every year, just with different timing. Custom special events are unique occurrences that don't repeat annually.

Does this help clarify why we might want a separate category for custom special events?

Let me clarify the distinctions between these event types: 1. **Static Events (Fixed Date)**: - Occur on the exact same date every year - Examples: Christmas (always December 25th) - These events have a consistent, fixed date that doesn't change from year to year 2. **Cyclical Events (Variable Date)**: - Occur annually, but on a varying date based on a pattern - Examples: - Thanksgiving (fourth Thursday of November) - Mother's Day (second Sunday in May) - These events happen every year, but the exact date shifts based on a specific rule 3. **Custom Special Events (Non-Recurring)**: - One-time or irregular events - These are different from both static and cyclical events because they don't follow a predictable yearly pattern The key difference is the recurrence pattern. Static and cyclical events will happen every year, just with different timing. Custom special events are unique occurrences that don't repeat annually. Does this help clarify why we might want a separate category for custom special events?
tobiichi3227 commented 2024-12-12 13:47:58 +00:00 (Migrated from github.com)
Copy Link

OK

OK
tobiichi3227 commented 2024-12-12 13:49:41 +00:00 (Migrated from github.com)
Copy Link

However, for events like the Moon Festival, which uses the lunar calendar and clearly occurs every year, the specific date still needs to be specified in custom_special.json.

However, for events like the Moon Festival, which uses the lunar calendar and clearly occurs every year, the specific date still needs to be specified in `custom_special.json`.
lifeadventurer commented 2024-12-12 13:55:29 +00:00 (Migrated from github.com)
Copy Link

However, for events like the Moon Festival, which uses the lunar calendar and clearly occurs every year, the specific date still needs to be specified in custom_special.json.

Exactly! Your example of the Moon Festival perfectly illustrates why we need the custom_special.json. Events like the Moon Festival, which follows lunar calendar calculations, don't fit neatly into the standard static or cyclical event types.

While they do occur annually, their dates can't be predetermined using a simple Gregorian calendar rule. They require specific date input each year, which makes them "custom" in nature. These events need a separate file where you can manually specify their exact dates, taking into account complex calendrical calculations.

So yes, custom_special.json remains crucial for handling these types of unique, annually occurring events that don't follow standard date patterns. It provides the flexibility to include events with more complex recurrence rules that can't be automatically generated.

custom_special.json: For one-time or irregular events, or events with complex date calculations (like the Moon Festival in the lunar calendar)

> However, for events like the Moon Festival, which uses the lunar calendar and clearly occurs every year, the specific date still needs to be specified in `custom_special.json`. Exactly! Your example of the Moon Festival perfectly illustrates why we need the `custom_special.json`. Events like the Moon Festival, which follows lunar calendar calculations, don't fit neatly into the standard static or cyclical event types. While they do occur annually, their dates can't be predetermined using a simple Gregorian calendar rule. They require specific date input each year, which makes them "custom" in nature. These events need a separate file where you can manually specify their exact dates, taking into account complex calendrical calculations. So yes, `custom_special.json` remains crucial for handling these types of unique, annually occurring events that don't follow standard date patterns. It provides the flexibility to include events with more complex recurrence rules that can't be automatically generated. `custom_special.json`: For one-time or **irregular events**, or **events with complex date calculations** (like the Moon Festival in the lunar calendar)
lifeadventurer commented 2024-12-12 13:57:27 +00:00 (Migrated from github.com)
Copy Link

This is exactly what I proposed in my initial review comment!

Any special event that does not fit into either:

  • Static events (fixed date every year)
  • Cyclical events (recurring on a pattern like "fourth Thursday")

Goes directly into custom_special.json.

This is exactly what I proposed in my initial review comment! Any special event that does not fit into either: - Static events (fixed date every year) - Cyclical events (recurring on a pattern like "fourth Thursday") Goes directly into `custom_special.json`.
lifeadventurer (Migrated from github.com) requested changes 2024-12-12 14:19:08 +00:00
CONTRIBUTING.md
lifeadventurer (Migrated from github.com) commented 2024-12-12 14:18:56 +00:00
Copy Link

The markdown headers didn't align with the filename.

The markdown headers didn't align with the filename.
Sign in to join this conversation.
Reviewers
No Reviewers
lifeadventurer
Labels
Clear labels
bug
Something isn't working
 documentation
Improvements or additions to documentation
 duplicate
This issue or pull request already exists
 enhancement
New feature or request
 good first issue
Good for newcomers
 help wanted
Extra attention is needed
 invalid
This doesn't seem right
 question
Further information is requested
 stale
Pull Request is stale
 waiting for merge
waiting for review
waiting for update
wontfix
This will not be worked on
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
ChenKaiLiuG
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: ChenKaiLiuG/life_generators#45
Delete Branch "feat/cyclical-special-event"

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?