I can't understand why gmdate() and date() reutrn the same values if my server is not configured to be on Greenwich Mean Time.
Why is this?
echo time(); // 1311011114
echo date("U"); // 1311011114
echo gmdate("U"); // 1311011114
echo date("j-m-y H:m:s"); // 18-07-11 12:07:14
echo date("e"); // America/Chicago
echo date("O"); // -0500
echo date("T"); // CDT
UPDATE
how do I obtain current time on Greenwich? calculating with date("O")? is there other way?
Because time never changes -- it is always seconds since epoch (GMT).
Time is always the same. It is just your time-zone is different and that is how display date differs.
You can change your timezone in order to see time in the different zones.
See here for all the Date/Time functions
So a long time ago, people needed a way to determine time across multiple computing systems that was uniformed. The Computing Syndicate Council of Wise Elders (CSCWE for short) of the pre-Internet age were the ones that decided upon this. A secret ballot decided the arbitrary beginning point would be 1970 to herald a more advance computing age. So from that moment onwards, an unending march of seconds through the decades began, a new time for computing revolution with the steady beat of the seconds.
From this arbitrarily defined beginning, all computing time can be determined by running mathematical wizardry against this ever increasing number of seconds and then factoring in the timezones.
It is already answered but if you want to get local time and UTC time;
date_default_timezone_set('America/Chicago');
$format = 'Y-m-d H:i:s';
$time1 = time();
$time2 = strtotime(gmdate($format));
print date($format, $time1);
print date($format, $time2);
// 2014-07-24 17:31:23
// 2014-07-24 22:31:23
Related
when i am trying to print 160000 in gmstrftime.it results 20:26 but for 80000 it gives 22:13. i am not sure why this happening.Is their any kind of limit for gmstrftime?
echo gmstrftime('%H:%M', 160000);
it gives 20:26.
echo gmstrftime('%H:%M', 80000);
it gives 22:13
Just as deceze pointed out the second arg is the epoch or unix time. Number of seconds since 1970 January 1 00:00. If you leave the second arg out you will get the current time.
<?php
$time1 = strtotime("2014-02-03 20:26");
echo "First time (".date('c', $time1).") in epoch: $time1\n";
echo gmstrftime('%H:%M', $time1)."\n";
$time2 = strtotime("2014-02-03 22:13");
echo "Second time (".date('c', $time2).") in epoch: $time2\n";
echo gmstrftime('%H:%M', $time2)."\n\n";
?>
Plug in different dates for $time1 and $time2 to see the epoch time.
160000 is not a timestamp in any way that PHP (or other common systems) define a timestamp. What you have is merely a time of day expressed in "military time" stored as an integer. So first of all, any gm function is likely not what you want to use, since you are missing timezone information from this "timestamp" to begin with, hence conversion to GM time is ambiguous if not impossible.
The best you may be able to do is:
$timestamp = DateTime::createFromFormat('His', sprintf('%06d', 160000))->format('U');
echo strftime('%H:%M', $timestamp);
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");
I am developing an website to run in Australia.
so i have set the time zone as follows.
date_default_timezone_set('Australia/Sydney');
I need to calculate number of days between two dates.
I found a strange behavior in the month of October.
$now = strtotime('2013-10-06'); // or your date as well
$your_date = strtotime('2013-10-01');
$datediff = $now - $your_date;
echo floor($datediff/(60*60*24));//gives output 5, this is right
$now = strtotime('2013-10-07'); // or your date as well
$your_date = strtotime('2013-10-01');
$datediff = $now - $your_date;
echo floor($datediff/(60*60*24));//gives output 5, this is wrong, but it should be 6 here
after 2013-10-07 it always give one day less in answer.
Its fine with other timezones. May be its due to daylight saving. But whats the solution for this.
Please help.
Thanks
Why it says 5, and why this is technically correct
In Sydney, DST begins at 2013-10-06 02:00:00 - so you lose an hour in dates straddling that.
When you call strtime, it will interpret the time as a Sydney time, but return a Unix timestamp. If you converted the second set of timestamps to UTC, you'd get a range from 2013-09-30 14:00:00 to 2013-10-06 13:00:00, which isn't quite 6 days, so gets rounded down to 5.
How to get the time difference ignoring DST transitions
Try using DateTime objects instead, e.g.
$tz=new DateTimeZone('Australia/Sydney');
$start=new DateTime('2013-10-01', $tz);
$end=new DateTime('2013-10-07', $tz);
$diff=$end->diff($start);
//displays 6
echo "difference in days is ".$diff->d."\n";
Why does DateTime::diff work differently?
You might ask "why does that work?" - after all, there really isn't 6 days between those times, it's 5 days and 23 hours.
The reason is that DateTime::diff actually corrects for DST transitions. I had to read the source to figure that out - the correction happens inside the internal timelib_diff function. This correction happens if all the following are true
each DateTime uses the same timezone
the timezone must be geographic id and not an abbreviation like GMT
each DateTime must have different DST offsets (i.e. one in DST and one not)
To illustrate this point, here's what happens if we use two times just a few hours either side of the switch to DST
$tz=new DateTimeZone('Australia/Sydney');
$start=new DateTime('2013-10-06 00:00:00', $tz);
$end=new DateTime('2013-10-06 04:00:00', $tz);
//diff will correct for the DST transition
$diffApparent=$end->diff($start);
//but timestamps represent the reality
$diffActual=($end->getTimestamp() - $start->getTimestamp()) / 3600;
echo "Apparent difference is {$diffApparent->h} hours\n";
echo "Actual difference is {$diffActual} hours\n";
This outputs
Apparent difference is 4 hours
Actual difference is 3 hours
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().
the following code:
// settings 1st alternative
$season = 2011;
$startweek = 36;
// calculation, 1st alternative
// in any case Jan 1st is in 1. week
$firstweekuniversal = mktime(0,0,0,1,4,$season);
// I'd like to calculate monday 0:00 of the given week.
// date(...) computes to monday of the calculated week.
$startday1 = $firstweekuniversal + 86400 * (7*($startweek-1) - date('w', $firstweekuniversal)+1);
// settings 2nd alternative
$StartingDate = "KW36 - 5.09.2011 (Mo)";
// calculation, 2nd alternative
$firstparts = explode(" ", $StartingDate);
$secparts = explode(".", $firstparts[2]);
$startday2 = mktime(0,0,0,intval($secparts[1]),intval($secparts[0]),intval($secparts[2]));
// Output
echo "Start: \$startday1=".$startday1.", Timestamp=\"".date("d.m.Y - H:i:s", $startday1)."\"<br>\n";
echo "Start: \$startday2=".$startday2.", Timestamp=\"".date("d.m.Y - H:i:s", $startday2)."\"<br>\n";
leads to this output:
Start: $startday1=1315177200, Timestamp="05.09.2011 - 01:00:00"
Start: $startday2=1315173600, Timestamp="05.09.2011 - 00:00:00"
where is the 1h difference coming from? It can't be summertime issues, in that case the 1h had to be the other way round, or am I wrong?
There's no difference, when I'm trying with my environment (localhost), but on the server of my prvider there is.
Can anyone explain this to me? I'm totally puzzled here.
Thanks in advance,
My understanding of daylight savings is that at a certain point between winter and summer the sun is starting to rise earlier, so at 8am it would feel like it should be 9am ... and that's exactly what the clock does, it moves forward making it later (by one hour typically). This is also why it's such a good excuse for being late at school :)
In any case, the timezone setting of your local php is probably UTC (or some other "neutral" timezone) but the server timezone setting honors daylight savings.