Allow schedule cron inputs to use a user-selected timezone (#1228) by lancepioch · Pull Request #2180 · pelican-dev/panel

lancepioch · 2026-02-06T07:32:41Z

Add a timezone dropdown (defaulting to the user's profile timezone) to the schedule form so cron inputs are interpreted in the chosen timezone. The selected timezone is used to compute next_run_at in UTC at save time with no database schema changes required.

Resolves #1228

Add a timezone dropdown (defaulting to the user's profile timezone) to the schedule form so cron inputs are interpreted in the chosen timezone. The selected timezone is used to compute next_run_at in UTC at save time with no database schema changes required. Resolves #1228

coderabbitai · 2026-02-06T07:32:48Z

Important

Review skipped

Draft detected.

Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

🔍 Trigger a full review

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

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

coderabbitai

Actionable comments posted: 4

🤖 Fix all issues with AI agents

In `@app/Filament/Server/Resources/Schedules/Pages/CreateSchedule.php`:
- Around line 42-53: The timezone assignment may throw a TypeError if user()
returns null; update the assignment in CreateSchedule (the $timezone line) to
use the null-safe operator on user() so it reads the same fallback order but
accesses user()->timezone safely (i.e., use user()?->timezone), leaving the rest
of the logic and the call to ScheduleResource::getNextRun unchanged.

In `@app/Filament/Server/Resources/Schedules/Pages/EditSchedule.php`:
- Around line 40-50: The timezone resolution uses a direct user() call; change
it to use the null-safe operator so missing user doesn't raise an error: when
computing $timezone before calling ScheduleResource::getNextRun, replace the
user()->timezone usage with user()?->timezone so the expression reads
$data['timezone'] ?? user()?->timezone ?? 'UTC' and then leave subsequent
unset($data['timezone']) and the ScheduleResource::getNextRun call unchanged.

In `@app/Filament/Server/Resources/Schedules/ScheduleResource.php`:
- Around line 103-106: The current assignment uses user()->timezone which can
throw if user() is null; update the null-coalescing to use null-safe access
(e.g., user()?->timezone) so $timezone = $get('timezone') ?? user()?->timezone
?? 'UTC'; locate this in ScheduleResource (the line that sets $timezone) and
replace the direct property access with the null-safe operator to prevent
TypeError during unauthenticated requests.
- Around line 300-306: The Select field for 'timezone' uses user()->timezone in
->default(...) which can throw if user() is null; change the default call in the
Select::make('timezone') chain to use the null-safe operator (user()?->timezone
?? 'UTC') so it safely falls back to 'UTC' when no user exists, keeping the rest
of the chain (options, searchable, live, hiddenOn) unchanged.

🧹 Nitpick comments (2)

app/Http/Controllers/Api/Client/Servers/ScheduleController.php (2)
78-78: Consider using null-safe operator for defensive coding.

While StoreScheduleRequest likely enforces authentication, using the null-safe operator maintains consistency with defensive patterns elsewhere in the codebase.
🛡️ Proposed fix
-            'next_run_at' => $this->getNextRunAt($request, $request->user()->timezone ?? 'UTC'),
+            'next_run_at' => $this->getNextRunAt($request, $request->user()?->timezone ?? 'UTC'),
134-134: Same null-safe pattern recommended here.
🛡️ Proposed fix
-            'next_run_at' => $this->getNextRunAt($request, $request->user()->timezone ?? 'UTC'),
+            'next_run_at' => $this->getNextRunAt($request, $request->user()?->timezone ?? 'UTC'),

coderabbitai · 2026-02-08T03:25:43Z

app/Filament/Server/Resources/Schedules/Pages/CreateSchedule.php

+        $timezone = $data['timezone'] ?? user()->timezone ?? 'UTC';
+        unset($data['timezone']);
+
        if (!isset($data['next_run_at'])) {
            $data['next_run_at'] = ScheduleResource::getNextRun(
                $data['cron_minute'],
                $data['cron_hour'],
                $data['cron_day_of_month'],
                $data['cron_month'],
-                $data['cron_day_of_week']
+                $data['cron_day_of_week'],
+                $timezone
            );


⚠️ Potential issue | 🟡 Minor

Apply null-safe operator for user() call.

Consistent with the same pattern used elsewhere in this PR, use the null-safe operator to prevent potential TypeError.

🛡️ Proposed fix

- $timezone = $data['timezone'] ?? user()->timezone ?? 'UTC'; + $timezone = $data['timezone'] ?? user()?->timezone ?? 'UTC';

📝 Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

Suggested change

$timezone = $data['timezone'] ?? user()->timezone ?? 'UTC';

unset($data['timezone']);

if (!isset($data['next_run_at'])) {

$data['next_run_at'] = ScheduleResource::getNextRun(

$data['cron_minute'],

$data['cron_hour'],

$data['cron_day_of_month'],

$data['cron_month'],

$data['cron_day_of_week']

$data['cron_day_of_week'],

$timezone

);

$timezone = $data['timezone'] ?? user()?->timezone ?? 'UTC';

unset($data['timezone']);

if (!isset($data['next_run_at'])) {

$data['next_run_at'] = ScheduleResource::getNextRun(

$data['cron_minute'],

$data['cron_hour'],

$data['cron_day_of_month'],

$data['cron_month'],

$data['cron_day_of_week'],

$timezone

);

🤖 Prompt for AI Agents

In `@app/Filament/Server/Resources/Schedules/Pages/CreateSchedule.php` around lines 42 - 53, The timezone assignment may throw a TypeError if user() returns null; update the assignment in CreateSchedule (the $timezone line) to use the null-safe operator on user() so it reads the same fallback order but accesses user()->timezone safely (i.e., use user()?->timezone), leaving the rest of the logic and the call to ScheduleResource::getNextRun unchanged.

coderabbitai · 2026-02-08T03:25:43Z

app/Filament/Server/Resources/Schedules/Pages/EditSchedule.php

+        $timezone = $data['timezone'] ?? user()->timezone ?? 'UTC';
+        unset($data['timezone']);
+
        $data['next_run_at'] = ScheduleResource::getNextRun(
            $data['cron_minute'],
            $data['cron_hour'],
            $data['cron_day_of_month'],
            $data['cron_month'],
-            $data['cron_day_of_week']
+            $data['cron_day_of_week'],
+            $timezone
        );


⚠️ Potential issue | 🟡 Minor

Apply null-safe operator for user() call.

Same pattern as CreateSchedule.php - use the null-safe operator for consistency.

🛡️ Proposed fix

- $timezone = $data['timezone'] ?? user()->timezone ?? 'UTC'; + $timezone = $data['timezone'] ?? user()?->timezone ?? 'UTC';

📝 Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

Suggested change

$timezone = $data['timezone'] ?? user()->timezone ?? 'UTC';

unset($data['timezone']);

$data['next_run_at'] = ScheduleResource::getNextRun(

$data['cron_minute'],

$data['cron_hour'],

$data['cron_day_of_month'],

$data['cron_month'],

$data['cron_day_of_week']

$data['cron_day_of_week'],

$timezone

);

$timezone = $data['timezone'] ?? user()?->timezone ?? 'UTC';

unset($data['timezone']);

$data['next_run_at'] = ScheduleResource::getNextRun(

$data['cron_minute'],

$data['cron_hour'],

$data['cron_day_of_month'],

$data['cron_month'],

$data['cron_day_of_week'],

$timezone

);

🤖 Prompt for AI Agents

In `@app/Filament/Server/Resources/Schedules/Pages/EditSchedule.php` around lines 40 - 50, The timezone resolution uses a direct user() call; change it to use the null-safe operator so missing user doesn't raise an error: when computing $timezone before calling ScheduleResource::getNextRun, replace the user()->timezone usage with user()?->timezone so the expression reads $data['timezone'] ?? user()?->timezone ?? 'UTC' and then leave subsequent unset($data['timezone']) and the ScheduleResource::getNextRun call unchanged.

coderabbitai · 2026-02-08T03:25:43Z

app/Filament/Server/Resources/Schedules/ScheduleResource.php

+                        $timezone = $get('timezone') ?? user()->timezone ?? 'UTC';
+
                        try {
-                            $nextRun = Utilities::getScheduleNextRunDate($get('cron_minute'), $get('cron_hour'), $get('cron_day_of_month'), $get('cron_month'), $get('cron_day_of_week'))->timezone(user()->timezone ?? 'UTC');
+                            $nextRun = Utilities::getScheduleNextRunDate($get('cron_minute'), $get('cron_hour'), $get('cron_day_of_month'), $get('cron_month'), $get('cron_day_of_week'), $timezone)->timezone($timezone);


⚠️ Potential issue | 🟡 Minor

Null safety issue: user() may return null.

The user() helper can return null when no user is authenticated. Accessing ->timezone on null will throw a TypeError. While this form likely requires authentication, it's safer to use null-safe access.

🛡️ Proposed fix using null-safe operator

- $timezone = $get('timezone') ?? user()->timezone ?? 'UTC'; + $timezone = $get('timezone') ?? user()?->timezone ?? 'UTC';

📝 Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

Suggested change

$timezone = $get('timezone') ?? user()->timezone ?? 'UTC';

try {

$nextRun = Utilities::getScheduleNextRunDate($get('cron_minute'), $get('cron_hour'), $get('cron_day_of_month'), $get('cron_month'), $get('cron_day_of_week'))->timezone(user()->timezone ?? 'UTC');

$nextRun = Utilities::getScheduleNextRunDate($get('cron_minute'), $get('cron_hour'), $get('cron_day_of_month'), $get('cron_month'), $get('cron_day_of_week'), $timezone)->timezone($timezone);

$timezone = $get('timezone') ?? user()?->timezone ?? 'UTC';

try {

$nextRun = Utilities::getScheduleNextRunDate($get('cron_minute'), $get('cron_hour'), $get('cron_day_of_month'), $get('cron_month'), $get('cron_day_of_week'), $timezone)->timezone($timezone);

🤖 Prompt for AI Agents

In `@app/Filament/Server/Resources/Schedules/ScheduleResource.php` around lines 103 - 106, The current assignment uses user()->timezone which can throw if user() is null; update the null-coalescing to use null-safe access (e.g., user()?->timezone) so $timezone = $get('timezone') ?? user()?->timezone ?? 'UTC'; locate this in ScheduleResource (the line that sets $timezone) and replace the direct property access with the null-safe operator to prevent TypeError during unauthenticated requests.

coderabbitai · 2026-02-08T03:25:43Z

app/Filament/Server/Resources/Schedules/ScheduleResource.php

+                        Select::make('timezone')
+                            ->label(trans('server/schedule.timezone'))
+                            ->options(fn () => array_combine(timezone_identifiers_list(), timezone_identifiers_list()))
+                            ->default(user()->timezone ?? 'UTC')
+                            ->searchable()
+                            ->live()
+                            ->hiddenOn('view'),


⚠️ Potential issue | 🟡 Minor

Apply the same null-safe fix to the default value.

Same issue as above - use the null-safe operator for consistency and safety.

🛡️ Proposed fix

- ->default(user()->timezone ?? 'UTC') + ->default(user()?->timezone ?? 'UTC')

🤖 Prompt for AI Agents

In `@app/Filament/Server/Resources/Schedules/ScheduleResource.php` around lines 300 - 306, The Select field for 'timezone' uses user()->timezone in ->default(...) which can throw if user() is null; change the default call in the Select::make('timezone') chain to use the null-safe operator (user()?->timezone ?? 'UTC') so it safely falls back to 'UTC' when no user exists, keeping the rest of the chain (options, searchable, live, hiddenOn) unchanged.

lancepioch requested review from Boy132, notAreYouScared and rmartinoscar February 6, 2026 07:32

lancepioch self-assigned this Feb 6, 2026

coderabbitai bot reviewed Feb 8, 2026

View reviewed changes

lancepioch added 2 commits February 7, 2026 23:23

Use null-safe operator on user() calls for timezone access

59f21ff

Remove unnecessary nullsafe operator on left side of ??

65ed068

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Allow schedule cron inputs to use a user-selected timezone (#1228)#2180

Allow schedule cron inputs to use a user-selected timezone (#1228)#2180
lancepioch wants to merge 3 commits intomainfrom
lance/1228

lancepioch commented Feb 6, 2026

Uh oh!

coderabbitai bot commented Feb 6, 2026 •

edited

Loading

Review skipped

Uh oh!

coderabbitai bot left a comment

Uh oh!

coderabbitai bot Feb 8, 2026

Uh oh!

coderabbitai bot Feb 8, 2026

Uh oh!

coderabbitai bot Feb 8, 2026

Uh oh!

coderabbitai bot Feb 8, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

Comments

Uh oh!

Conversation

lancepioch commented Feb 6, 2026

Uh oh!

coderabbitai bot commented Feb 6, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Review skipped

Uh oh!

coderabbitai bot left a comment

Choose a reason for hiding this comment

Uh oh!

coderabbitai bot Feb 8, 2026

Choose a reason for hiding this comment

Uh oh!

coderabbitai bot Feb 8, 2026

Choose a reason for hiding this comment

Uh oh!

coderabbitai bot Feb 8, 2026

Choose a reason for hiding this comment

Uh oh!

coderabbitai bot Feb 8, 2026

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

Comments

coderabbitai bot commented Feb 6, 2026 •

edited

Loading