[Settings]: System — Timezone

[nielsdrost7]

SMART Plan — Set cron/scheduled task frequency in System Settings

Specific

A Select field labelled "Recurring Invoice Frequency" in the System tab of the Company Settings page. Options: daily, weekly, monthly. Stores the selected value as a string under the key cron_frequency, scoped to the current company. Controls how often the Laravel scheduler runs the recurring invoice generation job for this company.

Measurable

• The field appears in the System section of the Company Settings page
• Saving the form persists the value to the settings table with key cron_frequency and company_id scope
• The value is read back correctly on page reload
• The scheduler reads this setting to determine the recurrence interval for this company's recurring invoices

Achievable

1. Create/extend Modules/Core/Filament/Company/Pages/CompanySettings.php (Filament page with tabs)
2. Add a Select::make('cron_frequency')->label('Recurring Invoice Frequency')->options(['daily' => 'Daily', 'weekly' => 'Weekly', 'monthly' => 'Monthly']) field to the System tab section
3. Add const CRON_FREQUENCY = 'cron_frequency'; to Modules/Core/Models/Setting.php constants
4. Register the page in CompanyPanelProvider

Relevant

Different companies have different invoicing cadences. A weekly-billing agency and a monthly-subscription SaaS both need recurring invoices, but at different intervals. Per-company control avoids running unnecessary jobs and prevents over- or under-billing.

Time-bound

Sprint 6.

---

Arrange · Act · Assert

// Modules/Core/Tests/Feature/CompanySettingsTest.php

#[Test]
public function it_saves_cron_frequency_setting(): void
{
    /* Arrange */
    $page = Livewire::actingAs($this->user)
        ->test(\Modules\Core\Filament\Company\Pages\CompanySettings::class);

    /* Act */
    $page->set('data.cron_frequency', 'weekly')
         ->call('save');

    /* Assert */
    $page->assertSuccessful();
    $this->assertDatabaseHas('settings', [
        'company_id' => $this->company->id,
        'key'        => 'cron_frequency',
        'value'      => 'weekly',
    ]);
}

[coderabbitai]

📝 CodeRabbit Plan Mode

Generate an implementation plan and prompts that you can use with your favorite coding agent.

• Create Plan

Examples

• Example 1
• Example 2

---

🔗 Similar Issues

Related Issues

• As an admin in the Company Panel, in the General Settings, I want to be able to set the Language #244
• As an admin in the Company Panel, in the General Settings, I want to be able to set the date format #246
• As an admin in the Company Panel, in the General Settings, I want to be able to set the first day of the week #245
• [Settings]: Company panel — assign Users #243
• [Settings]: General — Company Information #247

👤 Suggested Assignees

• nielsdrost7

---

🧪 Issue enrichment is currently in open beta.

You can configure auto-planning by selecting labels in the issue_enrichment configuration.

To disable automatic issue enrichment, add the following to your .coderabbit.yaml:

issue_enrichment:
  auto_enrich:
    enabled: false

💬 Have feedback or questions? Drop into our discord!

[nielsdrost7]

SMART Plan — System — Timezone

Specific

Within the Company panel Settings → System tab, add a Select field to choose the company's timezone (e.g., 'Europe/Amsterdam', 'America/New_York'). Stored as a settings row scoped to the company. All date/time calculations and displays use the selected timezone.

Measurable

• Timezone dropdown in CompanySettings.
• Selection stored as a settings row.
• All timestamps on invoices, reports, and dashboards reflect the company's timezone.
• Recurring invoice scheduling uses the company's timezone.
• Success message confirms timezone was updated.

Achievable

1. Add timezone settings key.
2. Add Select field in CompanySettings → System tab with a list of PHP timezone constants.
3. In services/observers, retrieve $company->setting('timezone') and apply via Carbon::setTimezone().
4. Update invoice timestamps to use the company's timezone.

Relevant

Multi-timezone companies need each business unit's data in the right timezone. This avoids confusion on invoice dates and recurring scheduling.

Time-bound

Sprint 6.

[nielsdrost7]

Refined SMART Plan (rewritten — the previous plan body didn't match this issue's title)

Note: the original SMART plan on this issue was for cron_frequency (recurring-invoice
scheduling), which doesn't match the "Timezone" title at all — and that field already shipped
separately as Setting::KEY_CRON_FREQUENCY in the System tab (from #686). This plan replaces it
with an actual timezone-preference plan.

Specific

A Select field labelled "Timezone" in the System tab of the Company Settings page
(Modules/Core/Filament/Company/Pages/CompanySettings.php), alongside the existing
cron_frequency/date_format/time_format fields. Options are populated from
DateTimeZone::listIdentifiers() (e.g. Europe/Amsterdam, America/New_York). Stores the
selected identifier as a string under a new Setting::KEY_TIMEZONE = 'timezone' constant,
scoped to the current company.

Scope note: today date_format/time_format/currency_code are all stored but not yet
consumed anywhere for actual date/number rendering — confirmed via a full-repo grep, there is
currently zero per-company timezone or date-format handling; the app runs on a single global
config('app.timezone') = 'UTC'. This plan matches that same existing scope tier: persist the
preference via the standard Settings mechanism. Wiring it into actual date display (converting
stored UTC timestamps to the company's timezone at render time, e.g. via a CarbonImmutable
helper or a view composer) is real follow-on work of comparable size to "apply date_format
everywhere dates render" — worth its own issue rather than silently expanding this one's scope.

Measurable

• The field appears in the System tab of the Company Settings page
• Saving the form persists the identifier to the settings table with key timezone and
  company_id scope
• The value is read back correctly on page reload
• An invalid/unrecognized timezone identifier cannot be saved (validate against
  DateTimeZone::listIdentifiers())

Achievable

1. Add public const KEY_TIMEZONE = 'timezone'; to Modules/Core/Models/Setting.php
2. Add the Select field to CompanySettings.php's System tab, ->options() built from
   DateTimeZone::listIdentifiers() (grouped/searchable — that list is ~400 entries)
3. Add Setting::KEY_TIMEZONE to CompanySettings::allKeys() (required or save()/mount()
   silently drop the field, per this repo's existing pattern)
4. Add 'timezone' => 'Timezone' translation key to resources/lang/en/ip.php

Relevant

Every company operates its own effective business hours/deadlines (invoice due dates, quote
expiry); a shared global UTC timezone with no per-company override means displayed
dates/deadlines don't reflect the company's actual locale. This is the same category of gap as
#249 (currency) already addresses for amounts.

Time-bound

Small — same shape as the already-shipped cron_frequency/date_format fields (~1 field + 1
constant + 1 translation key + tests). No date-rendering-pipeline work is in scope here.

Test plan

• CompanySettingsTest: save-then-reload round trip for timezone
• CompanySettingsTest: rejects an invalid timezone identifier
• CompanySettingsTest: multi-tenancy — company A's timezone setting doesn't leak into company B

[nielsdrost7]

Implementation plan (drafted, parked — not being worked today)

Posting this for documentation. Root cause of the long-skipped
DateFieldAutoPopulationTest::it_handles_timezone_differences_correctly test: it's not just
flaky (2-second real-clock tolerance racing a mid-test config() mutation), it's testing a
feature that doesn't exist — there is no per-company (or any) timezone concept anywhere in the
app, only a single hardcoded global config('app.timezone') = 'UTC'.

Checked InvoicePlane v1 (prep/v180 branch) for a reference implementation: v1 has no real
timezone feature either — only a UTC-fallback PHP bootstrap hook, no stored setting, no UI. This
would be new v2 functionality, not a port.

Critical finding that reshapes the naive design

Traced Filament's DatePicker → DateTimeStateCast pipeline: it forcibly re-expresses whatever
Carbon value is passed to ->default() into config('app.timezone') (UTC) unless
->timezone(...) is also explicitly set on the field — so a naive "swap now() for a
company-aware now()" change would have zero actual effect on stored values. ->timezone() is
the load-bearing change, not just ->default().

Also: invoiced_at's DatePicker has no ->native(false), so its internal format is date-only
(no time/offset) — the only meaningful, deterministic assertion for the rewritten test is
calendar-date equality (toDateString()), not full-instant equality. That's actually the correct
invariant anyway (a company near a UTC day-boundary should see their local date).

Plan when picked back up

1. Setting::KEY_TIMEZONE constant + Select field (options from DateTimeZone::listIdentifiers())
   on the Company Settings System tab; add to allKeys().
2. DateHelpers::now(?int $companyId = null): Carbon + DateHelpers::companyTimezone(?int $companyId = null): string,
   resolving via Setting::getForCompany(..., config('app.timezone')), company-id resolution
   mirroring the existing Filament::getTenant() → session pattern used in
   CompanySettings::getCompanyId().
3. Wire InvoiceForm's invoiced_at and QuoteForm's quoted_at DatePickers: add both
   ->timezone(DateHelpers::companyTimezone()) (load-bearing) and ->default(DateHelpers::now()).
   Deliberately not touching invoice_due_at/quote_expires_at or any other now() call site.
4. Rewrite the flaky test: set the company's timezone via Setting::saveForCompany() (not global
   config()), assert toDateString() equality against the test suite's already-frozen clock
   (Carbon::setTestNow()), remove markTestSkipped().
5. New unit tests in the existing DateHelpersTest.php for the allow-path (custom timezone) and
   boundary-path (unset, falls back to app default).
6. New branch off develop: feature/252-company-timezone.

Not scoped for today — parking here until picked back up.