Comments (3)
Appreciate the explanation, I still think this requires a substantial highlight in the upgrade docs
from carbon.
Hello, they are not identical because createFromTimestampUTC
has only 1 parameter, while createFromTimestamp
has a second $timezone
parameter so you can explicitly use:
Carbon::createFromTimestamp(time(), date_default_timezone_get());
The change is that we no longer assume that null
means date_default_timezone_get()
. And there are multiple reasons for that.
While you're switching from Carbon 2 to 3, I suggest you carefully consider them as it's possibly a good occasion to also change some settings that might help on the long run:
- timestamp is by definition: "Number of seconds since January 1st 1970 00:00 UTC" so for the sake of explicitness it makes sense to get an UTC date-time out of a timestamp value, then to change explictly the timezone with
->setTimezone()
- Having a default timezone other than UTC on server side does not make sense 99% of the cases, most of the application built using Carbon server requests that can potentially come from users if different timezone that whatever is configured on the server, if it does not, there is still chances that it would in the future, or that code would be reused later in another application that would. So there is a huge advantage to assume that server-side application should be timezone-agnostic and almost no advantage to assume the opposite. So when assuming server will serve request for devices/users that won't have all the same timezone, then the good value for default timezone is UTC (I.E.
date_default_timezone_set('UTC')
) as it's a neutral value, it has no DST, it has a fixed offset, while if you pick any arbitrary city timezone, it's dependent on government to change the offset if needed, and because it's arbitrary over standard, you have to bridge it when communicating with other systems. - timezone is not a server thing, it's a client/user thing, application should not then apply them globally, they should read it from user config/request header, use it only for processes that need to be user-contextualized and use UTC for the rest. When exchanging JSON data with front-end app, server typically don't even need to care about user timezone, because front app can format date-time as UTC before sending and build local time objects from UTC date-time string they would receive.
date_default_timezone_get()
is driven by php.ini config ifdate_default_timezone_set
is not (or not yet) called, which make it less reliable because it prevents you PHP code to be standalone, instead your application depends on how PHP is configured in order to behave as expected. Ifdate_default_timezone_get()
is never called you don't risk to break the app if you migrate it to another server that would be located somewhere else and so timezone config potentially different.
It's a though topic I tried to explain more in details here:
Always Use UTC Dates And Times
from carbon.
Documentation updated.
from carbon.
Related Issues (20)
- Unknown or bad timezone (:/etc/localtime) HOT 2
- Carbon::createFromFormat Incorrect Month Output for February HOT 1
- Error parsing date HOT 1
- Unserialize from Carbon v2 objects HOT 1
- Carbon createFromTimestampMs no default time zone if it is set in env variable of Laravel app HOT 1
- `CarbonInterval`'s `days` property return false HOT 2
- [Translation tool] sr_RS@latin
- Date difference problem HOT 5
- isSameDay: Too few arguments HOT 1
- Singular methods without parameters also work with parameters. It should not be as per the documentation. HOT 1
- Inconsistent Date Calculation When Adding Months Across February HOT 5
- Carbon\Carbon::rawAddUnit(): Argument #3 ($value) must be of type int|float, string given HOT 5
- Failed to parse time dd/mm/yyyy using parseFromLocale with Portuguese HOT 1
- Check month issue HOT 1
- PHP Version < 7.4 broken HOT 2
- Psalm reports MissingDependency on CarbonPeriod HOT 1
- Syntax Supported Only After PHP 7.4 Causes Errors in Versions Prior to 7.4 HOT 1
- Undocumented breaking change: isSameMonth() HOT 3
- CarbonPeriod loses timezone when accessing days
- Using "Depends on the following methods" @method in traits causes PHPStan to lose knowledge of type resulting in errors
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from carbon.