public
Created

Adding a month to a UNIX timestamp: C vs. PHP

  • Download Gist
addmonth.c
C
1 2 3 4 5 6 7 8
#include <time.h>
 
time_t add_month(time_t x) {
struct tm val;
localtime_r(&x, &val);
++val.tm_mon;
return mktime(&val);
}
addmonth.php
PHP
1 2 3 4 5 6 7 8 9 10 11 12 13 14
<?php
 
function add_month($x) {
$val = localtime($x);
return mktime($val[2], /* Cool... an array instead of a struct */
$val[1], /* And I don't even get to pass elements in order */
$val[0],
$val[4]+2, /* 0-based vs. 1-based month */
$val[3],
$val[5]+1900 /* 0-based vs. 1900-based year */
);
}
 
?>

Yup. PHP sucks if you don't know what you are doing:

function add_month($x) {
    $dateTime = new DateTime('@'.$x);
    $dateTime->modify('+1 month');

    return $dateTime->format('U');
}

To be fair, the functions I used are current and not marked as deprecated, and they highlight an example of the pervasive bad design in PHP. They didn't even have to design these functions—they were already part of POSIX. All they had to do was copy. How did they miss the "output of one function works as input to the other" feature?

I don't want to rehash the rest of the "PHP sucks" argument, so I'll refer to you my comment on The PHP Singularity and the post Jeff links to, PHP: A fractal of bad design. This is by no means the only thing broken in PHP.

Or if you want to get fancy:

function add_month($time) {
    return strtotime("+1 month", $time);
}

Simple enough for you?

Well to be honest I quote from your comment: "Sure, you can get work done in PHP, but I'm all for coming up with something better and using it wherever it makes sense.".

There is something better (right here in PHP) :-) and you should use it because it makes sense.

@PeeHaa, did you read my last comment? This is an example of one of many ridiculous quirks in PHP. I'll grant you this one's avoidable because there are other ways to do date processing in PHP. (That, in itself, is interesting: why do I need so many ways to add a month to a date? If one of them is obviously the best answer, why not deprecate the others, and have the documentation link to the better way to do things?)

Do you have something against PHP being replaced by a better language? That's the core of the argument… that better is possible, and we should seek it out, or create it if it doesn't exist yet. Or do you not believe a better language can exist?

If you're in the latter group, I refer you to Beating the Averages, specifically the section The Blub Paradox. It's hard to tell your current language is broken until you spend long enough with a better one.

Improvement is always possible. Of course we should work toward it.

PHP would be better if the glaring stupidity was fixed. From what I've seen the problem is not technical, it comes across as purely a lack of willingness to fix it. Even simple things like "add the 'finally' structure for exceptions" turns into a holy war of silliness (https://bugs.php.net/bug.php?id=32100#1335385953), or how PHP refuses to use the normal system timezone database (http://derickrethans.nl/distributions-please-dont-cripple-php-or-red-hat-stop-fucking-around.html, see Bryan Smith's reply).

@LnxPrgr3:

If one of them is obviously the best answer, why not deprecate the others, and have the documentation link to the better way to do things?

That answer is quite simple. Because every problem is different. Since every problem is different, some solutions are appropriate and others are not. Having options in this case is a good thing. It lets you think about the best solution...

Improvement is always possible. Of course we should work toward it.

Isn't that exactly what's been happening in PHP for the past decade? It's being improved time and again. Most of the points that are bad things are the result of legacy cruft. Deprecating and changing things takes a long time.. Especially for very well used functionality like mysql_* and date*()...

Sometimes we need to admit there's a difference between good and good enough...

Much of the recent movement in PHP, and libraries within PHP, has been to create sensible OO abstractions above the crazy. No-one's denying there aren't a lot of crazily-designed functions like mktime in PHP, but hardly any functions like this have been added since PHP4 - and PHP 5.0.0 was released very nearly 8 years ago.

I don't think PHP is a better language than the likes of Python, but the point is you don't need to use the vast majority of functions in the PHP standard library. This stuff doesn't kill you.

@ircmaxell:

Sometimes we need to admit there's a difference between good and good enough...

If I have a choice, I'm going to pick good over good enough. Why would I settle? Why would anyone settle?

If one of them is obviously the best answer, why not deprecate the others, and have the documentation link to the better way to do things?

That answer is quite simple. Because every problem is different. Since every problem is different, some solutions are appropriate and others are not.

Can you imagine a situation where I'd want to use mktime and localtime over the date objects? If so, then it's still very relevant that this API is unreasonable, since I might legitimately want to use it one day. If not, why can't we kill this silly cruft? Obviously not in PHP 5, since it would break existing code… but can't we deprecate it now and steer people to the DateTime object as a replacement, then kill this cruft in PHP 6?

@shieldo:

Much of the recent movement in PHP, and libraries within PHP, has been to create sensible OO abstractions above the crazy.

The crazy extends all the way down to the language. Unfortunately, you can't fix that with libraries, though I'm glad they're fixing as much as they are! My day job exposes me to PHP, so the better it gets, the happier I am… once we can ever upgrade to a newer version.

@LnxPrgr3:

I do agree that what's needed is more focus than there has been. The language itself, and especially the newer parts of it, has never been properly documented in an opinionated way. That may confuse newcomers, or people who have been programming PHP for ten years and never really taken a step back to look at the scenery and maybe get some first-principles computer science education. Others have called for a 'PHP: The Good Parts', and I would agree. PHP really needs, for example, a definite place to find how one uses things like the SPL and the intl extension - currently there's more or less a couple of blog articles and that's it. (And before anyone says anything: I know, I should get on that!)

I agree also with killing cruft of the likes of mktime for PHP6 - not because, practically, it's actually thaaaaaat much of a problem that it's there (arguing "bad PHP is bad" doesn't really get anyone anywhere), but more that things of the past, that have saner replacements, should just be put to bed so that there is more focus on aspects of the language that help you make things quicker and better. It is a giant broken window. For example, I'd love to be able to use Traversable objects interchangeably with arrays (i.e. pass them into array functions and suchlike), but that discrepancy doesn't quite stick out so much as a sore thumb when there's still so much of this old, opaque stuff kicking about the standard library.

There's a decent community of people working within PHP - I don't know what percentage of the total, and yes, it maybe is relatively small, but hope it serves as a beacon to others - who have worked extensively with other languages and libraries in other languages, but for whatever reason code within PHP, and not because it's perfect and there aren't, if one leaves aside critical mass (and one can't), better alternatives. Much of the tooling present in the ecosystems of other languages has recently become available in PHP - maybe not to the same extent, but to a comparable extent. Jeff Atwood wants PHP to be replaced by a better language - and yes, honestly, I really would wish people get into Python or Ruby first - but what would really help is a clear way for the very large constituency of web people who came in more by tinkering than by curated education to properly understand things like OOP as a concept, and not just a syntactical construct - because if everyone who tinkers with PHP now tinkered with Python instead, you'd still have the same problem. Horrible codebases like Magento (that will trumpet themselves as object-oriented) are a testament to a sufficient proportion of PHP programmers not understanding OOP properly as a concept.

Please sign in to comment on this gist.

Something went wrong with that request. Please try again.