If I set a time zone like:
date_default_timezone_set('America/Los_Angeles');
Will it affect the value of time()?
No, it does not. Your system knows the absolute time. Timestamps (time()) represent absolute timestamps. Timezone settings only affect human readable time formats as produced by date(), since those are relative to a specific location on earth (because 12:00 noon it typically when the sun is highest in the sky, and that varies between locations).
I don't believe so
Returns the current time measured in the number of seconds since the Unix Epoch (January 1 1970 00:00:00 GMT).
Note the GMT on the end.
Also read the first comment on the php.net for time()
The documentation should have this info. The function time() returns
always timestamp that is timezone independent (=UTC).
<?php
date_default_timezone_set("UTC");
echo "UTC:".time();
echo "<br>";
date_default_timezone_set("Europe/Helsinki");
echo "Europe/Helsinki:".time();
echo "<br>";
?>
Local time as string can be get by strftime() and local timestamp (if ever needed) by mktime().
Related
When I try to turn a german date (date of birth, to be more specific) format into a unix timestamp, I am getting -3600 instead of a 0.
Maybe some summertime thing?
$value = '01.01.1970';
$date = DateTime::createFromFormat ('d.m.Y', $value);
$date->setTime(0, 0);
$value = $date->getTimestamp();
echo $value; // -3600
I always thought there's a 0. What is the best practice when dealing with a situation like this? Timezone is GMT+1, in case it matters. I even tried 01.01.1850, turning it to timestamp and then back to a formated date. Works nicely at home, but at work it showed 31st December 1849.
I suspect, if you check with date_default_timezone_get, that your server's timezone is not set to UTC. I was able to duplicate this behavior like so:
date_default_timezone_set('Europe/Berlin');
$value = '01.01.1970';
$date = DateTime::createFromFormat ('d.m.Y', $value);
$date->setTime(0, 0);
$value = $date->getTimestamp();
Due to the timezone differences, 1970-01-01 00:00:00 in the Berlin timezone does, in fact, correspond to a negative Unix timestamp of -3600. The Unix timestamp 0 just corresponds to 1970-01-01 00:00:00 in UTC - a negative value simply indicates a time prior to that instant.
That is a great question. One which even threw me off, because of this.
However, in your case Germany was as you said on UTC+01:00, hence on your system the value of $date is 1970-01-01T00:00:00+01:00.
If you reverse the scenario and try to find out what is the date corresponding to timestamp 0, it should help you understand how time zones work with timestamps.
$date = DateTime::createFromFormat ('U', '0');
$date->setTimezone(new DateTimeZone('Europe/Berlin'));
echo $date->format(DATE_ATOM); // 1970-01-01T01:00:00+01:00
Because timestamps are the relative time difference from the UNIX epoch in seconds it will be a different time in different time zone. This count starts at midnight on January 1st, 1970 at UTC. While both Britain and Germany were on UTC+01:00 in 1970, the UNIX epoch started for them on 1970-01-01 01:00:00
In terms of how to best deal with this, well... that is opinion-based. Probably most people would tell you to deal with time in UTC so you don't run into weird issues such as this, and only convert to the right timezone on display, but even the great Jon Skeet had different opinion.
The output of the following is two identiacal lines of UTC
date_default_timezone_set('Europe/London');
$datetime = new DateTime();
echo "\n" . $datetime->format('U');
$datetime->setTimezone(new DateTimeZone('Pacific/Chatham'));
echo "\n" . $datetime->format('U');
They should obviously be different, and neither should be UTC!
As well as setting the timezone in the code, its set in php.ini as
date.timezone = 'Europe/London'
PHP version is PHP 5.6.30, and all appears to be working when you use the web-browser, running on OS X.
They should obviously be different, and neither should be UTC!
Completely wrong. Twice.
The U format specifier of DateTime::format() prints the date as a timestamp. As the documentation explains in the "Description" column, its meaning is "Seconds since the Unix Epoch (January 1 1970 00:00:00 GMT)"
You don't change the date or time stored in the $datetime object between the two calls to DateTime::format(), it is still the same date. The number of second passes since the Unix Epoch didn't change. There is no reason for the second call to DateTime::format() to print a different value.
Changing the timezone doesn't affect the date. It affects only how the date is represented using date & time components (years, months, days, hours, minutes, seconds, timezone).
A timestamp is an absolute representation of a date. It represents the number of seconds that passed since a fixed moment in the past. It doesn't depend on timezones.
Change the formatting to:
echo($datetime->format('U: Y-m-d H:i:s e')."\n");
and see for yourself:
1504791287: 2017-09-07 14:34:47 Europe/London
1504791287: 2017-09-08 02:19:47 Pacific/Chatham
I do
strtotime("2008-09-04")
Where 09 is the month and 04 is the day and I get the result:
1220500800
Which is Thu, 04 Sep 2008 04:00:00 GMT. Where does those 4 hours come from? I should get 1220486400 instead of 1220500800 from strtotime.
You can set timezone globally with function date_default_timezone_set('UTC');, or you can just set timezone locally when you call strtotime() function like:
echo strtotime("2008-09-04 +0000"); # 1220486400
As people above have said, you're likely suffering from a time zone mismatch. This function may be of use in debugging the issue: http://us3.php.net/date_default_timezone_get
The most common problems with PHP's strtotime are timezones and date-time formats. I will address those 2 points.
First the format. As suggested by others on stackoverflow use the iso 8601 date format YYYY-MM-DD (https://www.iso.org/iso-8601-date-and-time-format.html). For example, September 27, 2012 is represented as 2012-09-27.
Next the timeszones. The best of all , do not use any timezone use the Universal Coordinated Time UTC (which is universal time and corresponds with GMT without Daylight Saving). UTC is the time standard commonly used across the world. The world's timing centers have agreed to keep their time scales closely synchronized - or coordinated - therefore the name Coordinated Universal Time (https://www.timeanddate.com/time/aboututc.html).
So now we have the picture clear. To convert a date time into unixtimestamp do:
// Saves your local set Timezone.
$saveDDTZ = date_default_timezone_get();
// Sets the timezone to UTC
date_default_timezone_set("UTC");
// Converts a date-time into a unix timestamp (= 1560470400).
$unixTS = strtotime( "2019-06-14 00:00:00 UTC");
// Restore the timezone
date_default_timezone_set($saveDDTZ");
To restore a unix timestamp to a Date use:
// Saves your local set Timezone.
$saveDDTZ = date_default_timezone_get();
// Sets the timezone to UTC
date_default_timezone_set("UTC");|
$unixTS = 1560470400
$dateTime = date("Y-m-d H:i:s", $unixTS);
// Restore the timezone
date_default_timezone_set($saveDDTZ");
If you want to change the UTC date into a TimeZone use the difference of the UTC and the TimeZone and the Daylight Saving.
php > echo strtotime("now America/New_York")."\n";
1376459035 // -> 2013-08-14 05:43:55 - Wrong
php > echo strtotime("now UTC")."\n";
1376444635 // -> 2013-08-14 01:43:55 - OK
php > echo time()."\n";
1376444635 // -> 2013-08-14 01:43:55 - OK
Can anyone explain?
Is this some PHP's invention – timezone-"corrected" unix timestamps?
// edit:
I realize it makes no sense to even specify the timezone with "now". It does, however, with other relative times, e.g. "tomorrow midnight". There, depending on the timezone, "tomorrow" could be a day further away, depending on whether the timezone is over midnight already. The behavior is equally weird, just a bit harder to explain.
As explained on Unix time wiki, Unix Epoch is always in UTC. Thats why outputs from
echo strtotime("now UTC");
echo time();
are the same. According this info New York time zone is UTC -5 hours. With current daylight saving time +1 now it equally UTC -4 hours. That's why you got result 2013-08-14 05:43:55 (4 hours diff).
you are using
strtotime("now America/New_York") thats why it is showing unix timestamp in different timezone for string.
use this:
date_default_timezone_set("America/New_York");
If I run the following in PHP:
echo mktime(0,0,0,1,1,1970);
the returned value is -3600, not 0 as I expected.
The server is UK based, it's currently 21 Sep (i.e. BST summertime) (though I wouldn't expect this to affect the epoch timestamp) and per php.info: "Default timezone Europe/London".
Setting the daylight saving time flag also, as follows, gives:
echo mktime(0,0,0,1,1,1970,0); (i.e. the correct DST flag, 0 as 1 Jan not DST/BST)
returns -3600
echo mktime(0,0,0,1,1,1970,1); (the incorrect flag - setting 1 Jan as DST)
returns -7200
echo mktime(0,0,0,1,1,1970,-1); (i.e. DST flag not set - left to PHP to decide)
returns -3600
Does anyone know why the epoch would be returned as -3600, not 0, please?
When it was midnight on Jan 1st 1970 in British Summer Time, it was one hour to midnight in Greenwich Mean Time. Try setting the time zone to UTC instead:
date_default_timezone_set('UTC'); // or just change php.ini
mktime() is based on your current timezone. If you want to create a timestamp based on GMT you have to use the gmmktime() function.
gmmktime(0,0,0,1,1,1970)
code on ideone
Resources :
php.net - gmmktime()