Handy tool thanks! A few suggestions for your roadmap

[snoblenet]

Thank you for this handy tool.

I have few suggestions for your roadmap, in no particular order of impact or effort.

1. Timezones: The ability to read and write timestamps from the point of view of your current timezone. So, if my shell exported TZ=Sydney/Australia and the commit timestamp was 2025-11-21T00:34:00Z, all relevant UI would display a commit as having been made at 8.34am, not at 12.34am.

2. Relative Timestamps: The ability to enter a new timestamp by providing its relative value compared to the current timestamp. For example, --days +2 or --minutes -30.

3. Pre-filled Responses: When the UI asks you to enter a new timestamp, the current timestamp is pre-filled so you can quickly edit it using whatever vim/emacs/?? bindings you have setup in your shell before pressing Enter.

4. Author Date vs Committer Date: Absolutely clarity in the UI about whether you are viewing/changing the commit's author date, committer date or both.

5. Range Mode: The dream scenario, which would look something like this:

$ git log --oneline

sha4 9.00am
sha3 8.00am
sha2 7.00am
sha1 6.00am

$commit-date --range-mode

Select the first commit in your range:

# A fzf-like commit picker appears showing all non-pushed commits on the current branch
# other than the most recent one.
# The user picks sha1.

Enter a new timestamp for sha1:

--hours +1

Select the last commit in your range:

# A fzf-like commit picker appears showing all non-pushed commits on the current branch
# that are more recent than sha1.
# The user picks sha4.

Enter a new timestamp for sha4:

--hours -1

commit-date-changer will make the following changes:
  sha1: 6.00am => 7.00am
  sha2: 7.00am => 7.20am
  sha3: 8.00am => 7.40am
  sha4: 9.00am => 8.00am
  
Type YES to proceed or press any other key to cancel.

YES

$ git log --oneline

sha4 8.00am
sha3 7.40am
sha2 7.20am
sha1 7.00am

6. More That Dates: If you did implement Idea 5, you would have created a system for making systematic changes to a range of commits. That system could be abstracted and then used to apply any other handy fix, such as:

• Find every commit in this range where the Jira ticket ID is in the message twice†, and edit them so the Jira ticket ID is in each message once
• Find every commit in this range where the author email is your real email address, and edit them so the author email is now the GitHub email alias that forwards to your real email address
• Add or remove details like 🤖 Generated with [Claude Code](https://claude.com/claude-code)

---

† I've made this mistake when typing so quickly that I forget about my tool that automatically adds the current Jira ticket ID to every commit message.

[arbaev]

Hi, @snoblenet! Wow, these are really cool ideas! Thank you, I'll definitely try to implement them.