date_default_timezone_set
Sets the timezone that every date and time function in the script will use from that point on.
date_default_timezone_set(string $timezoneId): bool- Added in PHP 5.1.0
Parameters
| Parameter | Type | Description |
|---|---|---|
$timezoneId | string | A timezone identifier from the tz database, such as "UTC", "Africa/Lagos", "Asia/Hong_Kong" or "Europe/Lisbon". |
Return value
booltrue if the identifier was valid and the default timezone was changed, false if it was not recognised.
Errors
Does not throw. An unrecognised identifier returns false and leaves the previous default timezone in place.
The argument must be a tz database identifier. Offsets like +02:00 are not accepted, and neither are display-only abbreviations such as CEST, PST or EDT. Beware that a handful of abbreviation-looking names — EST, MST, HST, CET, GMT, UTC — are real legacy zones in the tz database, so they are accepted and return true even though they carry no daylight saving rules.
Example
When to use it
- Pinning an application to UTC in its bootstrap file so behaviour is identical across servers
- Validating a timezone a user picked from a dropdown before storing it on their profile
- Rendering a scheduled job's log timestamps in the operations team's local zone
Frequently asked questions
Where should I call date_default_timezone_set?
Once, at the very start of your bootstrap, before any date is formatted or parsed. Setting it later means earlier code already ran under a different zone.
Can I pass an offset like +02:00 or an abbreviation like EST?
An offset like +02:00 is rejected and the function returns false. Abbreviations are a mixed case: CEST, PST and EDT are rejected, but EST, MST, HST, CET, GMT and UTC are legacy zone names that actually exist in the tz database, so date_default_timezone_set('EST') returns true. Prefer a full identifier such as Europe/Berlin or America/New_York, since only those carry daylight saving rules.
Does date_default_timezone_set change the system clock or affect other requests?
No. It only affects PHP's date functions inside the current process, and it never touches the operating system clock. In a long-running process it does persist past the current request, which is why bootstrap is the right place for it.
More examples
Validating a user-supplied timezone
The boolean return is the validity check. Note that legacy names such as EST5EDT are still in the tz database and are accepted, while an invented name is rejected and leaves the default untouched.
<?php
$previous = date_default_timezone_get();
foreach (['Europe/Lisbon', 'EST5EDT', 'Middle/Earth'] as $candidate) {
$ok = @date_default_timezone_set($candidate);
echo str_pad($candidate, 16), $ok ? "accepted\n" : "rejected\n";
}
date_default_timezone_set($previous);
echo 'restored: ', date_default_timezone_get(), "\n";Preferring DateTimeZone over the global setting
Three zones are rendered without touching global state, so nothing else in the request is affected. This is the pattern to use for per-user display; date_default_timezone_set stays a one-time bootstrap call.
<?php
date_default_timezone_set('UTC');
$moment = new DateTimeImmutable('2025-07-04 12:00:00');
foreach (['UTC', 'Europe/Berlin', 'Asia/Kolkata'] as $zone) {
$local = $moment->setTimezone(new DateTimeZone($zone));
printf("%-14s %s\n", $zone, $local->format('Y-m-d H:i P'));
}
echo 'default unchanged: ', date_default_timezone_get(), "\n";
Discussion