This question already has answers here:
Convert one date format into another in PHP
(17 answers)
Closed 4 years ago.
I have a DB that shows when the user made the last login but then it shows 1542575966120. I wanted it to show so 18/11/2018 19:00
I tried using this in php
$intDate = "20". $ infologado ["lastlogin"];
$newDate = date ("d-m-Y", strtotime ($ intDate));
but I could not.
sorry for English
So as #Taha Paksu had mentioned, these numbers are a timestamp (seconds since 1 January 1970). Try this code:
$intDate = 1542575966120;
$newDate = date('d/m/Y H:i', $intDate/1000);
It is in miliseconds, date function accepts seconds, thus the division by 1000. Also no need to put it into strtotime, because this function is meant to convert string dates to... said numeric timestamps.
In your case, you can put $intDate = $infologado['lastlogin']; instead of first line to get the result dynamically from the database.
First of all, you need to learn what a timestamp is. The timestamp is a number which shows the seconds passed (or milliseconds, some include the milliseconds too) since epoch (01/01/1970). A general definition can be found here:
The Unix epoch (or Unix time or POSIX time or Unix timestamp) is the number of seconds that have elapsed since January 1, 1970 (midnight UTC/GMT), not counting leap seconds (in ISO 8601: 1970-01-01T00:00:00Z). Literally speaking the epoch is Unix time 0 (midnight 1/1/1970), but 'epoch' is often used as a synonym for 'Unix time'. Many Unix systems store epoch dates as a signed 32-bit integer, which might cause problems on January 19, 2038 (known as the Year 2038 problem or Y2038).
The converter on this page converts timestamps in seconds, milliseconds and microseconds to readable dates.
Taken from: https://www.epochconverter.com/ a tool which you can convert your dates to/from timestamps or vice versa.
Then to answer your question, the system saved the dates as a timestamp to the database to (probably) bypass the formatting errors on each different system that uses it.
Nevermind, TL;DR:
The number shows Sunday, 18 November 2018 21:19:26.120 when you give it to the timestamp converter I mentioned above. With PHP, you can use:
$unixTimestamp = 1542575966120;
$dt = DateTime::createFromFormat("U.u", $unixTimestamp / 1000);
var_dump($dt);
to convert to PHP DateTime class, then you can use it in your application.
Related
I'm working on some time related features and I opt to always use UTC times and store time stamps as integers for consistency.
However, I noticed that when I use mktime it seems that the currently set time zone has an influence of the return value of mktime. From the documentation I understand that mktime is supposed to return the number of seconds since epoch:
Returns the Unix timestamp corresponding to the arguments given. This
timestamp is a long integer containing the number of seconds between
the Unix Epoch (January 1 1970 00:00:00 GMT) and the time specified.
http://php.net/manual/en/function.mktime.php
However, it seems that mktime is including the time zone that is currently set. When using the following code:
date_default_timezone_set('UTC');
$time = mktime(0, 0, 0, 1, 1, 2016 );
echo "{$time}\n";
date_default_timezone_set('Australia/Sydney');
$time = mktime(0, 0, 0, 1, 1, 2016 );
echo "{$time}\n";
I would expect the two time vales to be same but apparently they are not:
1451606400
1451566800
Which seems to be exacly an 11 hour difference:
1451606400 - 1451566800 = 39600 / (60*60) = 11
What do I not understand correctly about mktime and/or why is the time zone taken into account when using mktime?
I can't tell you why it is the way it is (PHP has never made sense to me when it comes to date and time) but there is an alternative function gmmktime() which is
Identical to mktime() except the passed parameters represents a GMT date. gmmktime() internally uses mktime() so only times valid in derived local time can be used.
There is also a comment on the PHP documentation for this function which explains how mktime(), gmmktime() and time() work. Essentially, they assume that you always think in time zones even if a UNIX timestamp itself doesn't carry a timezone.
Resulting Unix timestamp are indeed encoded in a timezone agnostic way, but input arguments are interpreted relative to the timezone set for current process. And indeed, Sidneys 2016-01-01 00:00:00 (GMT+11) happened 11 hours before UTC 2016-01-01 00:00:00.
When some foreigner tells you a time, you have to know its time zone to correctly interpret it, and so does mktime().
If dates you want to pass to mktime() are UTC dates, then use gmmktime() which exists for that purpose.
This question already has answers here:
How to calculate the difference between two dates using PHP?
(34 answers)
PHP: strtotime is returning false for a future date?
(5 answers)
Closed 8 years ago.
I need to calculate age in php.
I use this solution:
$birthdate = '1986-09-16';
$_age = floor( (strtotime(date('Y-m-d')) - strtotime($birthDate)) / 31556926);
from here
Everything works fine, but for example if
$birthday = '1194-01-06' or
$birthday = '1900-01-01'
result is always 44.
if $birthday = '1910-11-09' everything is fine again and result is 103. Why?
Note: I don't want to use diff() function, because of some issues.
EDIT:
Earlier i had problems with diff(), some
Warning range()
showed during processing and after refreshing of website everything was fine again... i could not find solution to fix it and somewhere i read that using of diff() could cause it. So i tried other solution and it worked... until now.
Finally I used this solution:
$birthDate = from database in timestamp format...
$birth = new \DateTime($birthDate);
$now = new \DateTime;
$age = $now->diff($birth)->y;
and I randomly get
Warning
range(): step exceeds the specified range
again.
It's because you're using date that is using timestamp that has a default value of time() that is based on EPOCH that started on January 1 1970 00:00:00 GMT - it's 44 years since 1970.
More on this can be found in the PHP Manual: http://php.net/manual/en/function.date.php
Integer limit issue, either:
Your OS doesn't handle negative timestamps
The maximum integer values for signed integers on a 32 bit system
strtotime()
The valid range of a timestamp is typically from Fri, 13 Dec 1901 20:45:54 UTC to Tue, 19 Jan 2038 03:14:07 UTC. (These are the dates that correspond to the minimum and maximum values for a 32-bit signed integer.)
Additionally, not all platforms support negative timestamps, therefore your date range may be limited to no earlier than the Unix epoch (1 Jan 1970).
Have you read strtotime() manual (https://php.net/manual/en/function.strtotime.php)?
The function expects to be given a string containing an English date format and will try to parse that format into a Unix timestamp (the number of seconds since January 1 1970 00:00:00 UTC), relative to the timestamp given in now, or the current time if now is not supplied.
I am working with php and mysql to develop my application. For this application, time plays an important role as I want to show data to my users according to their selected timezone. For this i am using strtotime to convert time into numeric form, but I just noticed that strtotime returns same value for all timezones. I wrote following code to test.
date_default_timezone_set("Asia/Kolkata");
echo date("Y-m-d H:i:s")." ------ ";
echo strtotime(date("Y-m-d H:i:s"))."<br/><br/>";
date_default_timezone_set("America/New_York");
echo date("Y-m-d H:i:s")." ------ ";
echo strtotime(date("Y-m-d H:i:s"));
But output is
2013-01-28 15:40:11 ------ 1359367811
2013-01-28 05:10:11 ------ 1359367811
Why is the return value identical?
strtotime() returns "the number of seconds since January 1 1970 00:00:00 UTC"
As #Bobby's comment states, "Unix Timestamps are always UTC". This means you're essentially making two equivalent conversions to the UTC timezone.
Consider that a t1 timestamp in a1 timezone and the same t1 timestamp in a2 would produce the same result when converted to timezone a3. In your example, the "same result" is in seconds, but the principle is the same.
In other words, in your code you are generating two UNIX timestamps from seemingly two different dates. But what you're actually doing is generating two different but equivalent representations (Asian and American timezones) of the same point in time. You then convert the two equivalent representations to the same third represntation (UTC timezone).
As per PHP manual for strtotime,
The function expects to be given a string containing an English date format and will try to parse that format into a Unix timestamp (the number of seconds since January 1 1970 00:00:00 UTC), relative to the timestamp given in now, or the current time if now is not supplied.
As stated above, strtotime converts a given date format into a Unix timestamp, which is calculated relative to the Unix epoch. The epoch is a fixed point whose definition is independent of the user's timezone, and the number of seconds since then is, relatively, the same in all time zones.
Setting the timezone merely affects the interpretation of the timestamp value.
When I am converting date using strtotime() function it automatically added 1 hour in existing date.
For example:
$PublishDate = "1/13/2012 **17**:0";
echo strtotime($PublishDate);
// OUTPUT : 1/13/2012 **18**:0
Why 1 hour is incremented automatically?
Something odd is going on here. strtotime() converts attempts to convert a string representation of a date to the Unix time format (see the strtotime() documentation). Unix time is the total number of seconds since January 1st, 1970. This ends up being a large number, such as 1326723022 (the current Unix time as of writing). You can read more about Unix time here.
strtotime() should ALWAYS return either a 32 bit integer or FALSE (-1 in older versions of php).
Excel's date format is, I believe, the # of days since December 30, 1899. (Why? Because it's based on 1/1/1900 but they erroneously include a leap day in 1900, and it's one-based. So it's fine for the first couple of months in 1900 but then it goes wrong. 1/1/1901 in Excel is "367".)
So, how can I convert a date or timestamp from PHP (which is typically stored as a Unix timestamp, the # of seconds since 1/1/1970) to Excel?
In PHP 5.1.6?
Yeah, bet you didn't see that one coming. So I don't have any of the DateTime objects, date_create(), date_diff(), etc. functions available to me.
Is it even possible without simply recording the Excel day for 1/1/1970 and working from there? And is there a DST-proof version?
If I'm not mistaken, there are 86400 seconds in a day, and 25569 days between 30 Dec 1899 and 01 Jan 1970. So, to convert a Unix timestamp to an Excel date, the formula
ExcelDate = 25569 + UnixTS / 86400
ought to work. Of course, this formula is only correct for UTC. (Also, it ignores leap seconds.) For other timezones, if you know the offset (in seconds!) from UTC, you can just add it to the timestamp before using the formula above.