MaterialDatePicker timezone bug

[ulibte]

The bug is that the reminder is set to a day before of my date.
To reproduce this bug you have to have a specific timezone and hour, in my case I tested with GMT-3 and 11:00 AM, after this you just create a reminder.
I read that MaterialDatePicker timezone is UTC, and Calendar.getInstance() choose the timezone of the device, so I think this bug is happening because my timezone is GMT-3.
I tested with this change and it worked.

2026-03-08.14-17-33.mp4

Summary by CodeRabbit

• Bug Fixes
  • Fixed timezone handling in date picker to use UTC timezone for consistent date selection across different regions.

[coderabbitai]

📝 Walkthrough

Walkthrough

A single-file change that modifies timezone handling in the DatePickerFragment by replacing a standard Calendar instance with one explicitly using UTC timezone when processing date picker selections.

Changes

Cohort / File(s)	Summary
Timezone Update app/src/main/java/com/philkes/notallyx/presentation/activity/note/reminders/DatePickerFragment.kt	Added TimeZone import and modified Calendar instantiation to use UTC timezone when extracting year, month, and day from date picker selections.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~8 minutes

Poem

🐰 A rabbit picked the UTC light,
No more timezone confusion, all right!
In UTC's glow, dates stand true,
From picker to calendar, through and through! 🕐

🚥 Pre-merge checks | ✅ 2 | ❌ 1

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 0.00% which is insufficient. The required threshold is 80.00%.	Write docstrings for the functions missing them to satisfy the coverage threshold.

✅ Passed checks (2 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title directly describes the main change: fixing a MaterialDatePicker timezone bug that causes reminders to be set to the wrong date.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment

Tip

Try Coding Plans. Let us write the prompt for your AI agent so you can ship faster (with fewer bugs).
Share your feedback on Discord.

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

🧹 Nitpick comments (1)

app/src/main/java/com/philkes/notallyx/presentation/activity/note/reminders/DatePickerFragment.kt (1)

19-19: Consider applying the same UTC fix for initial selection.

Line 19 creates a Calendar using local timezone, and its timeInMillis is passed to setSelection(). Since MaterialDatePicker interprets the selection value as UTC, this could cause the picker to initially display the wrong date for users in certain timezones (e.g., if date represents 11 PM on March 8 in GMT-3, that's March 9 UTC, and the picker would pre-select March 9).

This is pre-existing behavior and not strictly part of this fix, but worth considering as a follow-up.

♻️ Suggested fix for consistency

- val c = date?.let { Calendar.getInstance().apply { time = it } } ?: now + val c = date?.let {  + Calendar.getInstance(TimeZone.getTimeZone("UTC")).apply { time = it }  + } ?: Calendar.getInstance(TimeZone.getTimeZone("UTC")).apply { + timeInMillis = now().timeInMillis + }

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed. In `@app/src/main/java/com/philkes/notallyx/presentation/activity/note/reminders/DatePickerFragment.kt` at line 19, The initial selection Calendar is created in the local timezone (val c = ...), but MaterialDatePicker expects selection in UTC which can shift the displayed day for some timezones; update the creation of the selection Calendar in DatePickerFragment so it is a UTC-based Calendar (e.g., Calendar.getInstance(TimeZone.getTimeZone("UTC"))) and, when using the existing date variable, apply date to that UTC Calendar (or normalize to UTC midnight) before passing c.timeInMillis into setSelection() on the MaterialDatePicker so the picker pre-selects the intended date across timezones. 

🤖 Prompt for all review comments with AI agents

Verify each finding against the current code and only fix it if needed. Nitpick comments: In `@app/src/main/java/com/philkes/notallyx/presentation/activity/note/reminders/DatePickerFragment.kt`: - Line 19: The initial selection Calendar is created in the local timezone (val c = ...), but MaterialDatePicker expects selection in UTC which can shift the displayed day for some timezones; update the creation of the selection Calendar in DatePickerFragment so it is a UTC-based Calendar (e.g., Calendar.getInstance(TimeZone.getTimeZone("UTC"))) and, when using the existing date variable, apply date to that UTC Calendar (or normalize to UTC midnight) before passing c.timeInMillis into setSelection() on the MaterialDatePicker so the picker pre-selects the intended date across timezones. 

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro

Run ID: 3622d9ce-731a-4b51-8605-69dca0b8d6be

📥 Commits

Reviewing files that changed from the base of the PR and between 0a1ce31 and 289f601.

📒 Files selected for processing (1)

• app/src/main/java/com/philkes/notallyx/presentation/activity/note/reminders/DatePickerFragment.kt