feat: Add strftime format support to --after flag for consistent time parsing

[Copilot]

Problem

The --after flag was missing strftime format parsing support that already existed in the --before flag. When users set a custom time format using --time-style with +FORMAT (like date(1)), the --before flag could parse dates in that format, but --after could not, leading to inconsistent behavior.

Solution

Added the missing strftime parsing logic to the --after flag by mirroring the existing implementation from the --before flag. Both flags now consistently support:

• Standard time formats: MM-dd, MM-dd HH:mm, HH:mm, YYYY-MM-dd, YYYY-MM-dd HH:mm
• Custom strftime formats when --time-style is set with +FORMAT

Example Usage

# Both flags now work consistently with strftime formats
g --time-style="+%Y-%m-%d" --after="2025-07-03" .
g --time-style="+%m/%d/%Y" --before="07/03/2025" .
g --time-style="+%Y-%m-%d %H:%M" --after="2025-07-03 14:30" .

# US date format
g --time-style="+%m/%d/%Y" --after="07/03/2025" .

# ISO format with time
g --time-style="+%Y-%m-%d %H:%M:%S" --before="2025-07-03 14:30:00" .

Changes Made

• Added strftime parsing block to --after flag in internal/cli/filtering.go
• The implementation checks if the format starts with + and uses strftime.Parse() accordingly
• Maintains backward compatibility with existing time format parsing
• Error handling works correctly for invalid date formats

Testing

• Verified both flags work with various strftime formats (%Y-%m-%d, %m/%d/%Y, %Y-%m-%d %H:%M)
• Confirmed error handling for invalid dates
• Ensured fallback to standard time parsing still works
• All existing tests continue to pass

Fixes #245.

---

💬 Share your feedback on Copilot coding agent for the chance to win a $200 gift card! Click here to start the survey.

[equationzhao]

remove fmt.Println err in both before and after flag action

[Copilot]

Removed the debug fmt.Println(err) statements from both the before and after flag actions. Also cleaned up the unused fmt import. (b1a3434)