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

2024-12-03T15:10:55Z

tobiichi3227 commented

2024-12-03 15:10:55 +00:00

(Migrated from github.com)

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

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

static_special.json for events with fixed dates.
cyclical_special.json for recurring events (e.g., holidays like Thanksgiving and Mother's Day).
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

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;
}

Readability: The nested else and validation blocks make the code harder to read. Refactor to flatten the structure where possible.
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.
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

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

感恩節 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

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

感恩節 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

中秋節 (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)

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

static_special.json for events with fixed dates.

cyclical_special.json for recurring events (e.g., holidays like Thanksgiving and Mother's Day).

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)

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

static_special.json for events with fixed dates.

cyclical_special.json for recurring events (e.g., holidays like Thanksgiving and Mother's Day).

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)

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:

static_special.json for events with fixed dates
cyclical_special.json for recurring events
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)

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)

Let me clarify the distinctions between these event types:

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
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
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)

OK

tobiichi3227 commented

2024-12-12 13:49:41 +00:00

(Migrated from github.com)

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)

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)

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

The markdown headers didn't align with the filename.

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: ChenKaiLiuG/life_generators#45