I'm setting up a configuration file for a website, which will be read using the parse_ini_file method. One of the options is number of seconds prior to some action. I tried setting the value to 60*60*24*3 to get three day's worth of seconds:
[mailer]
; Number of seconds before trial expiration an email should be sent
seconds = 60*60*24*3;
but the variable is just read into php as the string "60*60*24*3". I don't want to use eval, for security reasons. Is there any way to make this (a) easier to use and (b) more intuitive to read than by simply listing the number of seconds to a given date?
You can use supported date and time formats to make a human-readable string, which may then be used to initialize and calculate the difference in seconds:
$diff = "3 days 5 hours 10 seconds";
$now = strtotime('2010-04-01 00:00:00'); // No leap year funny business
$then = strtotime($diff, $now);
$diff = $then - $now;
echo "
Now: " . date('r', $now) . "
Then: " . date('r', $then) . "
Diff (seconds): $diff";
https://ignite.io/code/51338967ec221e0d3b000000
Note: The concern about leap year is whether it will calculate the seconds correctly (add/remove a day?). If this is possible, it should be tested independently.
The above outputs:
Now: Thu, 01 Apr 2010 00:00:00 +0000
Then: Sun, 04 Apr 2010 05:00:10 +0000
Diff (seconds): 277210
Which would then let you do:
[mailer]
; Period before trial expiration an email should be sent.
; Use PHP-supported time statements in an expression to
; specify an interval, such as 3 days, or 72 hours, etc.
; See: http://www.php.net/manual/en/datetime.formats.php
expires = 3 days;
As I noted in the comments, you can also use DateTimeInterval::createFromString() with DateTime::diff to do the same thing.
I will note as well that getting the string formatted correctly, while not difficult, can sometimes be trickier than you might think. For simple strings like 3 days that's not hard, but 3d doesn't work. So the time that is calculated should be validated, and an error provided to the person setting the configuration if what was entered is not a valid expression, or is "out of bounds" to what was expected (in the past maybe?).
rename your ini to php and write it this way
# Number of seconds before trial expiration an email should be sent
$cfg['somesection']['someparam'] = 'foo';
...
$cfg['mailer']['seconds'] = 60*60*24*3;
or use a screen calculator to do the math and paste result as a value.
Related
$new_date = date('Y-m-d', strtotime("+2 days"));
or
$new_date = date('Y-m-d', strtotime("+48 hours"));
Are they same or different
Are they same or different
They are quite different. Objectively speaking, 2 days does not always equal 48 hours.
Consider crossing a daylight-savings boundary.
For example, 2019-04-07T02:00:00+1100 (AEDT -> AEST)
$twoDays = new DateInterval('P2D');
$fortyEightHours = new DateInterval('PT48H');
$ref = new DateTimeImmutable('2019-04-07T01:00:00',
new DateTimeZone('Australia/Melbourne'));
echo 'Reference: ', $ref->format('r'), PHP_EOL;
echo 'Plus 2 days: ', $ref->add($twoDays)->format('r'), PHP_EOL;
echo 'Plus 48 hours: ', $ref->add($fortyEightHours)->format('r'), PHP_EOL;
This produces
Reference: Sun, 07 Apr 2019 01:00:00 +1100
Plus 2 days: Tue, 09 Apr 2019 01:00:00 +1000
Plus 48 hours: Tue, 09 Apr 2019 00:00:00 +1000
Note, HHVM produces a different result for some reason
Demo ~ https://3v4l.org/L4tKo
This list of common date / time related falsehoods is worth checking out ~ https://github.com/kdeldycke/awesome-falsehood#dates-and-time
It's worth pointing out that using the same reference date and manipulating it with strtotime() produces different results to those above.
Demo ~ https://3v4l.org/O6MTd
I suspect this is because its relative time calculations aren't as nuanced as DateInterval.
Semantically they are different, as demonstrated by Phil in the other answer. This means that in some other libraries that account for this the difference is real.
However, the implementation of strtotime() does not take this into account, so given your example, it makes no difference.
I was interested if it can be followed up through source code, so here goes:
Implementation of strtotime() does this:
strtotime() starts, calling timelib_strtotime() to create the initial ts construct
timelib_strtotime() calls scan() to parse the string
it reads the string you've given to it, and one of the tokens it gets is your +2 days or +48 hours, which is considered as relativetext.
for relativetext, among other things, timelib_set_relative() is called
in timelib_set_relative() it does a lookup from using timelib_lookup_relunit(), which uses timelib_relunit_lookup array, finding that you've provided either a construct with type TIMELIB_DAY, value 1, multiplier 2, or construct TIMELIB_HOUR, value 1, multiplier 24
It saves the information from previous call to s->time->relative construct
this construct gets passed on, until strtotime calls timelib_update_ts with it (and with timezone info!)
in timelib_update_ts we call do_adjust_relative() to act on it. We do it without using time zone parameter, which I would think is the critical mistake
do_adjust_relative() calls timelib_do_normalize()
timelib_do_normalize() for hours does do_range_limit(0, 24, 24, &time->h, &time->d), increasing days and decreasing hours if hours are over the hardcoded limit which is 24, and for days does do_range_limit_days(), increasing months and decreasing days if we are over the limit, taking into account leap time (but NOT time zones!).
on returning to timelib_update_ts, we call do_adjust_timezone with timezone parameter, but at this point we've already made all the adjustments and we know no more if it was done with +48 hours or with +2 days. Thus it makes no difference.
TLDR: strtotime() does not take time zones into account when doing the conversion, so in that function it makes no difference, even though it really should.
I am working on project (a Google Transit feed) where I am required to provide the times for each stop on a bus route in the following common format: 21:00:00 and so forth.
Problem is, if times continue past midnight for a given trip, they require it to continue the hour counting accordingly. They explain quite specifically that 02:00:00 should become 26:00:00 and 03:45:00 should become 27:45:00 etc.
I am baffled on how to display such with any of the date() or strtotime() functions.
The only thing I can think of in my particular situation would be to function match and replace any strings in my output between 00:00:00 and 04:00:00, as that would clearly mean (again, for me only) that these are trips originating before midnight, but I don't feel that's the correct way.
Well seeing as it's only displaying on the page, you can
firstly get your date from where ever
Let's say $date = 00:00:00
$exploded_date = explode(":", $date);
This takes $date and puts it into an array so
$exploded_date[0] is hh
$exploded_date[1] is mm
$exploded_date[2] is ss
Then what you can do is use ltrim() to remove the leading 0 from 00 to 04 $exploded_date[0] - This makes it comparable in the if statement I'll do after
if($exploded_date[0] <= 4) {
$exploded_date[0] = ltrim($exploded_date[0], "0");
$exploded_date[0] = $exploded_date[0]+24;
}
Then you can implode the array back together into one string
$date = implode(":", $exploded_date);
// if the hour is 00 to 04 it will come out as 24 to 28
// e.g. 24:35:30
echo $date;
Despite giving you an answer. It's a silly thing to be doing, but it's not your choice so here you go :)
The way you display something doesn't necesarily has to be the same way you store something.
I don't know how you calculate the times, but assuming you have a start date and time, and some interval, you could calculate the end time as follows:
date_default_timezone_set('Europe/London');
$start_datetime = new DateTime('2014-11-11T21:00:00');
$next_stop = new DateTime('2014-11-12T02:00:00');
echo $start_datetime->format('Y-m-d H:i'); // 2014-11-11 21:00
echo $next_stop->format('Y-m-d H:i'); // 2014-11-12 02:00
$interval = $start_datetime->diff($next_stop);
// display next stop: 2014-11-11 26:00
echo ($start_datetime->format('Y') + $interval->y) .'-'
. ($start_datetime->format('m') + $interval->m) .'-'
. ($start_datetime->format('d') + $interval->d) .' '
. ($start_datetime->format('H') + $interval->h) .':'
. ($start_datetime->format('i') + $interval->i);
What I'm doing: create the start date (& time) and the datetime of the next stop. With the DateTime::diff() function I'm calculating the difference, and then, only for display (!) I add up each year, month, day, hour and minute to the datetime year, month etc. of the next stop.
This way you can still store your dates and times in a way every human being and computer system will understand (because let's be honest; to represent a time as 27:45 PM is quite ridiculous...)
I don't know if you only want the hours to be added up and roll over the 24 hour, or also days in a month etc. It's up to you how you handle these cases. Good luck!
I need help.. Is this right?
Start Date: Mar 16, 2014
End Date: Mar 19, 2014
Results: 2 Days
$plantEnd = get_the_author_meta('plantEnd', $sellerID );
$plantStart = get_the_author_meta('plantStart', $sellerID );
$future = $plantEnd;
$d = new DateTime($future);
echo $d->diff(new DateTime())->format('%a').' Days';
Why does it says 2 days? Isn't it 3 days? Im confused..
Since you aren't actually using $plantStart in your code and instead using the current time, you're basically getting a difference between now (the time the script was run, on server's time zone) and the start of Mar 19, 2014 (0h:0m:0s). So what you are really getting is something like 2 days 5 hours 3 minutes 25 seconds (depending on when you run it vs. server time.
for example, when I run this locally:
$d->diff(new DateTime())->format('%d:%H:%i:%s');
I get 2:04:59:25
So there's more to it than just getting that "2" returned.. you're just not formatting for it.
And again, you aren't actually using the $plantStart anywhere either. So if you were to do this:
<?php
$plantEnd = '2014-03-19';//get_the_author_meta('plantEnd', $sellerID );
$plantStart = '2014-03-16'; //get_the_author_meta('plantStart', $sellerID );
$future = $plantEnd;
$d = new DateTime($future);
echo $d->diff(new DateTime($plantStart))->format('%d:%H:%i:%s');
?>
You will see it outputs 3:00:0:0 (or you could continue to just use %d and get the "3"). This is because $plantStart (presumably - based on your post) just specifies yyyy-mm-dd, so passing just the yyyy-mm-dd value will put the hh:mm:ss at 0:0:0 (beginning of day) , so it will be a full day's calculation, which has the effect of "rounding up" to the whole day increment.
I have a feeling that it's actually 2 days, someodd hours, and someodd minutes, or something to that effect. Because you're formatting to just do days, you're losing the nuances. I'd change the code to say "2.4 days" (and for the life of me I can't remember how I did this in the past...)
EDIT: in the past I have simply used date() instead of DateTime().
I did a little research, and you might want format('%d')." Days";
Please check the following examples:
$date1 = strtotime("tomorrow 4:00 PM");
$date2 = strtotime("16:00:00");
$date3 = strtotime("10 hours");
$date4 = strtotime("+1 day");
echo date("Y m d H:i:s",$date1)."<br>";
echo date("Y m d H:i:s",$date2)."<br>";
echo date("Y m d H:i:s",$date3)."<br>";
echo date("Y m d H:i:s",$date4)."<br>";
It gives me the output as below:
2013 06 10 16:00:00
2013 06 09 16:00:00
2013 06 09 20:50:25
2013 06 10 10:50:25
I am considering first two example($date1 and $date2) as absolute data and the last two as relative date. Now, with only given the $date1/$date2/$date3/$date4 variables, is it possible to say whether it is relative time or an absolute time please?
I did get a solution on another thread: PHP datetime string differentiation
But that worked until I considered the 2nd example($date2 as an absolute value), where it doesn't work. Also, may suggested for regular expression checks, but that doesn't seem reliable either.
I was just wondering if php had some integrated way to tell this either from its functions or DateTime objects. I searched for, but didn't found anything.
Looking forward to listen for your suggestions/feedbacks/possible solutions. Thanks.
There is no direct way, AFAIK but there is a trick that you can use with the second parameter to the strtotime function.
function is_absolute_time($time_string) {
$time_shift = time() + 60; // 1 min from now
$time_normal = strtotime($time_string);
$time_shifted = strtotime($time_string, $time_shift);
return $time_normal == $time_shifted;
}
The rationale is simple: If the time is absolute, a 1 min difference won't change the calculation by strtotime and both $time_normal and $time_shifted will be same. For relative times, however, the difference will be one minute (the value in $time_shift variable).
There is a caveat with this code though. This function will return FALSE even for absolute times (but not absolute dates) less than 1 minute from midnight. You can minimize this by changing $time_shift to:
$time_shift = time() + 5; // 5 seconds from now.
This code will now work properly until 5 seconds from midnight. I think you can go safely to as low as 2. There is an edge case that 1 second in future might not work.
To fix this problem altogether, you can try a different approach:
function is_absolute_time($time_string) {
$epoch = 0; // Epoch
$time_shift = 60; // 1 min from epoch
$time_normal = strtotime($time_string, $epoch);
$time_shifted = strtotime($time_string, $time_shift);
return $time_normal == $time_shifted;
}
You can try this last solution directly. I am just building up the reason for the solution throughout this post.
Given only the value 2013 06 10 16:00:00 the answer is simple: it's absolute. Whether this absolute timestamp was created as "absolute" timestamp or based on relation to another date is impossible to tell. All you have is "2013 06 10 16:00:00", there's no "residual relativeness" or anything of that kind still in it.
Even this is relative to the supposed birth of Christ though, which is relative to the earth floating around in space since the Big Bang... *trollface*
Either I'm losing my mind, or I've not got the faintest idea what I'm doing. I'm leaning towards the latter.
I'm trying to convert this: 1316826000, which I'm pretty confident should be Sat, 24 Sep 2011 01:00:00 GMT
http://www.onlineconversion.com/unix_time.htm confirms this.
http://www.unixtimestamp.com/index.php tells me 09 / 23 / 11 # 8:00:00pm EST, so far so good. I happen to be in EST, this is the result I'd like to get back from PHP.
When I do date('l, M d, Y, h:ia', $iTime), I get: Friday, Sep 23, 2011, 12:00am, a full 20 hours off.
I've confirmed the server's time is correct using date('c'). date('c') output is: 2012-05-19T03:19:20+00:00. The server is in the central time zone, where it is currently 10:20pm. May 18.
echo date_default_timezone_get() outputs "GMT" (set somewhere else in the script using date_default_timezone_set('GMT'))
What am I missing? Nothing I've read so far can explain how I'm getting a result 20 hours behind what it should be. Were it an hour fast or slow, I could at least wrap my head around it being some sort of DST idiotry, but 20? Crazyness! Thanks for reading!
Check what your php.ini says for date.timezone.
In unix it is usually here: /etc/php.ini
Then use a proper timezone recognized by PHP:
http://www.php.net/manual/en/timezones.php
date.timezone = 'America/New_York'
Then reload your web server.
Unix time just means the number of seconds since epoch. Has nothing to do with timezones. Timezones simply add or subtract 1 hour (3600 seconds) from the unix time for each zone you move away from GMT.
An example:
$userTimezone = new DateTimeZone('America/New_York');
$gmtTimezone = new DateTimeZone('GMT');
$myDateTime = new DateTime('2014-01-22 11:44', $gmtTimezone);
$offset = $userTimezone->getOffset($myDateTime);
echo $offset;
That will output: -14400 or 4 hours. Which is the difference between New York and GMT
Using some Java code with the Joda-Time 2.3 library, as I don't know PHP…
long m = 1316826000L;
DateTime dateTimeUtc = new DateTime( m * 1000L, DateTimeZone.UTC );
DateTime dateTimeNewYork = dateTimeUtc.toDateTime( DateTimeZone.forID( "America/New_York" ) );
System.out.println( "dateTimeUtc: " + dateTimeUtc );
System.out.println( "dateTimeNewYork: " + dateTimeNewYork );
I can tell you that 1316826000 seconds from the beginning of 1970 UTC/GMT (Unix Epoch) is…
dateTimeUtc: 2011-09-24T01:00:00.000Z
dateTimeNewYork: 2011-09-23T21:00:00.000-04:00
So, as the commenter stated, it would be 8 PM in EST but EST was not in effect on that day. DST (Daylight Saving Time) (idiocy, as you correctly noted) was in effect until November 9 of that year (2011). So the time of day is pushed forward one hour, to 9 PM.
In GMT/UTC, that means 1 AM in the morning of the next day.
Standard time in east coast US is 5 hours behind UTC/GMT. With DST it is 4 hours behind UTC/GMT (one hour closer).
Where you got confused:
Your time format/conversion in incorrect.I can't help with that as I don't know PHP.
You should be using a competent date-time library for this kind of work.Date-time work is complicated, tricky, confusing, and error-prone.This question discusses possibilities of Joda-Time (for Java) sorts of libraries for PHP.
You used three-letter time zone codes. Avoid these.Those codes are neither standardized nor unique -- there are common duplicates. Instead, use proper time zone names. In your case of east coast US, "America/New_York". Furthermore, in this case you confused the time zone area and rules (east coast US) with a particular application of those rules (EST). Saying "America/New_York" means "whatever time zone rules were in effect on that date, whereas saying "EST" (if interpreted to mean Eastern Standard Time in US) means "UTC-05:00". So either (a) use a time zone name such as "America/New_York", or (b) use a specific offset such as "-05:00".