earmsby's avatar

Should I change the timezone for my server?

I have a filament app on a forge server which has a widget to fetch my WooCommerce orders for today. The WooCommerce site is on a completely different server and I use the API to interact with it on my filament app.

I fetch orders like this:

        //get today's orders
        $today_start = date('Y-m-d') . 'T00:00:00';
        $today_end = date('Y-m-d') . 'T23:59:59';
        $params=[
            'after'=>$today_start,
            'before'=>$today_end,
            'status' => 'processing,completed'
        ];
        $orders_today=$woocommerceClient->get('orders',$params);
	    ... etc.

The trouble is when it fetches orders later in the day, the server thinks it's already tomorrow and shows zero orders. It seemed to me that simply changing the server's timezone to my own and the same as the WooCommerce site, that would solve this problem.

FWIW, I don't have any chron jobs on this server. Also, no high stakes date fields in my database. In addition, this is not a public-facing site - just a dashboard only I use to manage some things.

Are there reasons not to change the timezone?

0 likes
4 replies
LaryAI's avatar
LaryAI
AI
2 months ago
Best Answer
Level 58

Great question! You're running into a classic timezone trap when integrating two different systems.

Short answer:
Yes, it is usually safe to change your server's timezone to match your WooCommerce site's timezone, especially given your use case (private dashboard, no critical DB timestamps, no cron jobs, etc.). This will likely solve your immediate issue with "today's" dates aligning between your servers.

However... There are a few broader things to consider:

1. Laravel and Timezones

Laravel (and PHP) handle timezones in three places:

  • PHP's default timezone (php.ini, or via date_default_timezone_set),
  • The "app" timezone (config/app.php → timezone), and
  • The database timezone (typically UTC).

Best practice is often to keep your server in UTC and adjust the app timezone for display or calculations. This prevents surprises if you ever add new team members, automate backups, run scheduled tasks, or log events shared with others in different regions.

2. Direct Date Usage and API Filtering

Your code directly uses PHP’s date() function. By default, this is based on the server's timezone. If the server drifts into "tomorrow" earlier than your WooCommerce site, your queries won’t align — exactly as you're seeing.

3. The Real Fix: Make Timezone Explicit

Rather than rely on the server’s system timezone, it's safer to set your PHP/Laravel app and date calculations to use your desired timezone explicitly.
Change the timezone in PHP or Laravel, not on the server's system itself.

If you use Laravel

Set the app's timezone to match your WooCommerce site:

// config/app.php
'timezone' => 'America/Los_Angeles', // or whatever your shop uses

Then, generate your dates using Carbon:

$today = Carbon\Carbon::now()->startOfDay();
$tomorrow = Carbon\Carbon::now()->endOfDay();

$params = [
    'after' => $today->format('Y-m-d\TH:i:s'),   // T00:00:00
    'before' => $tomorrow->format('Y-m-d\TH:i:s'), // T23:59:59
    'status' => 'processing,completed',
];

$orders_today = $woocommerceClient->get('orders', $params);

If you just use PHP

Set the default timezone at the top of your script:

date_default_timezone_set('America/Los_Angeles'); // Or your WooCommerce timezone

$today_start = date('Y-m-d') . 'T00:00:00';
$today_end = date('Y-m-d') . 'T23:59:59';

$params = [
    'after' => $today_start,
    'before' => $today_end,
    'status'  => 'processing,completed',
];

$orders_today = $woocommerceClient->get('orders', $params);

Summary

  • Yes, you can safely change your server timezone given your low-risk scenario.
  • But, it's usually better to control the timezone from your PHP/Laravel app layer!
  • This avoids surprises if something changes on the server, or if you deploy to another host in the future.

If changing the timezone in your code isn’t feasible, then updating the server is fine for your case. But if you want maximum portability and future-proofing: do it in your application layer!

If you need help with this in Laravel or PHP, let me know!

1 like
Glukinho's avatar

You shouldn't touch your server's timezone. What if you have another system to communicate with - are you going to change your server settings again? This is not way to go.

You should send correct timestamps to WooCommerce instead.

If WooCommerce can accept timestamps with timezone - prepare timestamps with timezone:

$today_start = (new \DateTimeImmutable('today 00:00:00'))->format(DATE_ATOM);
$today_end = (new \DateTimeImmutable('today 23:59:59'))->format(DATE_ATOM);

// assuming your time zone is +5 it gives you:
// start: 2026-01-31 00:00:00+05:00
// end:   2026-01-31 23:59:59+05:00

If it can't accept timezones - know which time zone WooCommerce operates in and tune timestamps with that time zone implicitly:

// assuming WooCommerce timezone is UTC:

$today_start = (new \DateTimeImmutable('today 00:00:00'))->setTimezone(new \DateTimeZone('UTC'))->format('Y-m-d H:i:s');
$today_end = (new \DateTimeImmutable('today 23:59:59'))->setTimezone(new \DateTimeZone('UTC'))->format('Y-m-d H:i:s');

// start: 2026-01-30 19:00:00
// end:   2026-01-31 18:59:59

As a general rule, a timestamp (a value referring to a point in time) must always exist with timezone explicitly defined, to prevent bugs like you have now.

This is bad as it refers to different point in time depending on where the value is interpreted:

2026-01-31 11:22:33

Good, explicit and solid value:

2026-01-31 11:22:33+05:00

Another general rule: always operate with dates using libraries provided by PHP and Laravel: DateTime, DateTimeImmutable, Carbon. They are really made for purpose. Don't rely on simple string manipulation.

1 like
martinbean's avatar

@earmsby No. You should leave your application’s timezone as UTC. If you need to query some API with non-UTC dates, then shift them.

1 like
earmsby's avatar

For posterity, I used the solution from Larry AI: 3. The Real Fix: Make Timezone Explicit Worked like a charm.

Please or to participate in this conversation.