I have a problem with processing a SQL Server database dump in PHP.
I have one column called datatime with values like :
0x0000a0af00d7f2eb
I need to extract, in PHP, the date and time values of this column. I don't have SQL Server available so I can't use the obvious solution of CAST(0x0000a0af00d7f2eb AS datetime).
Someone has told me that this hex: 0000a0af00d7f2eb is created by 4 bytes of date and 4 bytes of time.
So I know that:
When I will change 0000a0af (first 4 bytes) to decimal I will get number of days from 1900. That works fine.
But when I'm trying to change last the 4 bytes (so there should be time) : 00d7f2eb to decimal I'm getting something which I can't understand. It should be a time from midnight in milliseconds and sometimes this value is ~3 times lower.
Could anyone help in converting 0000a0af00d7f2eb to date? I know that time is between 5 AM and 11 PM, and the day is in last week.
According to the linked article in the other question linked to by Rene, SQL Server stores 3.33 millisecond intervals in the second set of 4 bytes, not milliseconds. So if you're calculating with milliseconds, you will indeed be getting a time about 1/3 of what it should be. Using your example, let's start by converting to decimal
00d7f2eb -> 14152427 3.3ms intervals
Now multiply out by 3.3 to convert to milliseconds, and divide by 1000 to get seconds
14152427 * 3.3 / 1000 ~ 47127.58
So this represents about 47 thousand seconds after midnight. Dividing by 3600 seconds in an hour
47127.58 / 3600 ~ 13.091
So this represents a time of about 13.1 hours after midnight, which agrees with the result of the cast done in SQL Server.
select CAST(0x0000a0af00d7f2eb AS datetime) as t
is working fine for me. and it returns 'August, 16 2012 13:06:14-0700'.
Related
I just found out, running a calendar script, that timestamps in PHP has a limit to 2038. What does it really mean? Why is it 2038 instead of 2050 or 2039? Why a limit if timestamps just count seconds from a given date (1970)?
The limit is imposed by the 4 byte signed integers that most C libraries use for representing that count. Quick math (assumes 365 day years, not exactly correct):
2147483648 seconds ~ 68.1 years
This also implies a lower limit of ~1900. Some libraries have started to introduce 64 bit epoch counts, but they are few and far between for the moment.
The maximum value of a signed 32-bit integer is 2,147,483,647. If you add +1 to that, you get -2,147,483,647. 2,147,483,647 seconds from 01-01-1970 00:00:00 is January 19, 2038. If you add one more second, you get a date somewhere in 1902.
due to the limit of INT datatype on 32 bit machine
http://php.net/manual/en/function.mktime.php
From php.net :
"The maximum possible date accepted by mktime() and gmmktime() is dependent on the current location time zone.
For example, the 32-bit timestamp overflow occurs at 2038-01-19T03:14:08+0000Z. But if you're in a UTC -0500 time zone (such as EST in North America), the maximum accepted time before overflow (for older PHP versions on Windows) is 2038-01-18T22:14:07-0500Z, regardless of whether you're passing it to mktime() or gmmktime()."
my guess is that it is stored in a fixed number of bits, which means a limit on how big the timestamp can get. We could do some math to figure it out exactly.
I have been trying to use the DateTime class to calculate an interval.
I use the unix timestamp from $_SERVER['REQUEST_TIME'] and a time retrieved from the database to get an interval, which is of time DateInterval. That part works.
That interval could be, for example, 5 minutes and 10 seconds since a process began.
My expected time for that process to complete is 10 minutes, and I want to inform the user that there is 4 minutes, 50 seconds expected time left.
$running_time; // calculated before, type DateInterval. Echoing the formatted value shows correct time
// (only problem is no leading 0's for single-digit minutes/seconds in format: '%i:%s')
$total = new DateTime('10:00'); // ten minutes, 0 seconds expected total running time
$time_left = $total->diff(new DateTime($running_time->format('%i:%s'))); // fatal error
I think this would work, except that, oddly, the format function is not working as expected. The minutes and seconds do not have leading zeros when they are single digits.
Any hints?
Yeah, the PHP documentation is off on this one.
Capitalize your I and S and you'll get your leading zeroes.
$running_time->format('%I:%S')
This seems like there should be a very easy solution, however everything I'm trying is either giving me an error or the wrong result.
I'm pulling data from a MySQL table and the time is stored in the Epoch format in the database. When I make the query on the website it's showing: 3672 (the same number shown in the database). I've tried using the date() function, a number of different str* functions, different arithmetic operations, however nothing is giving me the actual time, which should be showing as: '1:02'.
I'm not trying to pull the date, actual time, etc. I'm just trying to convert an Epoch time string to a traditional 'H:mm' format, because these are for durations, not timestamps.
Any help would be greatly appreciated!
As others already noticed, this is not really any standard epoch time but simply number of seconds since midnight.
Looking at your example, you only need hours and minutes (rounded up). This will give you those:
$h = (int)($number / 3600);
$m = ceil(($number - $h * 3600) / 60);
$result = sprintf('%d:%02d', $h, $m);
Dividing number by 3600 (60 for seconds * 60 for minutes) will give you number of hours. Using your example of 3672 this will give you 1.
To get minutes you just remove hours to get seconds (72) and then divide that by 60 to get minutes (1 minutes and 12 seconds). Since your example specifies 1:02 is result, you can simply take next upper integer (2).
At end result is 1:02, as you specified.
Can someone please help me with the following.
I am using php and sql to query a microsoft access database. I have a Date/Time field called "StartTime" that is set to "General date" format.
When inspecting the field from within the microft access GUI the date appears as "08:45:00".
My problem is when I retrieve this data with my php and sql and then display it in then write it to the browser it appears as follows "1899-12-30 09:00:00" (let's call this 'long date format' for what i'm about to say).
I have tried messing around with the php date function using the 'long date format' as the second argument but I can't seem to get it to display in the browser in the format "08:45:00".
Please can someone tell me what I need to do.
Thanks
The problem is that MS Access stores the date as a double with fractions. So you need to parse it accordingly.
The whole part of the number is the amount of days from Dec 30 1899. The fractional portion is the fraction of the day. So you need to multiply the fraction by 24 to get hours, multiply the resulting fraction by 60 to get minutes, and multiply the resulting fraction by 60 to get seconds.
Alternatively, you can multiply the fraction by 86400 (number of seconds in 24 hours), and then use a PHP function to convert the seconds into the time of day.
Check out this article:
http://support.microsoft.com/kb/210276
You could ask Access' db engine to give you only the time portion of those Date/Time values as formatted strings:
SELECT Format(StartTime, "hh:nn:ss") AS time_only
FROM YourTable;
That way you wouldn't have to transform the values in PHP ... just use them.
I am converting PHP (v 5.2.17)-based reports to SSRS.
I'm trying to write a query that subtracts dates like the php file does.
The date calculation either matches exactly, or it differs by exactly 3600 seconds
$timediff=strtotime(date("Y-m-d"))-strtotime("03/29/2007");
print $timediff; // 137635200
select (trunc(sysdate) - to_date('03/29/2007','MM/DD/YYYY'))*60*60*24 from dual
-- returns 137635200 - matches
$timediff=strtotime(date("Y-m-d"))-strtotime("11/23/2009");
print $timediff; // 53823600
select (trunc(sysdate) - to_date('11/23/2009','MM/DD/YYYY'))*60*60*24 from dual
-- returns 53827200 - doesnt match - off by 3600
I've searched stackoverflow and found the following example which sounds like it (11/23/2009 is a monday, and so is today 8/8, but it doesnt differ in the same way) PHP Strtotime erratic function
My assumption is that the php calculation is wrong, and the oracle is correct.
What say you? ;-)
Thanks!
Without seeing the exact values I suspect its because one of them is adjusting for daylight savings and the other is not. Most parts of the world change to/from daylight savings time during march. So in your first example both dates are in the same GMT offset, but in the second (November) they're not.
So one of your platforms (probably Oracle) is taking this one hour shift into account and the other is not.
3600 = an hour so could be timezone differences?
53827200 = ( 623 * 60*60*24 )
So 53827200 is exactly 623 days of 24 hours.
53823600 is 622.958333 days or 622 days (of 24 hours) plus 23 hours.
Both are right, for a given definition of right.