Simpelweg omdat je iets niet begrijpt maakt het nog niet fout.
De bovenstaande datum (25-09-2015 00:00:00) is een string. (EDIT daarbij: alle data uit $_GET, $_POST etc. zijn per definitie strings)
Strings volgen een andere sortering dan getallen.
Als je had gedaan wat SanThe voorstelt (het formaat YYYY-MM-DD gebruiken) dan waren deze twee sorteringen gelijk geweest. Dat formaat is niet voor niets een (ISO?) standaard.
Het beste is altijd om data in zijn "rauwe" variant op te slaan. Formattering in een of andere vorm doe je bij het afdrukken. Er zijn legio functies om een standaard datum formaat om te zetten naar een custom (en voor mensen prettiger leesbaar) formaat.
Maar het is goed dat je hier tegenaan loopt, hopelijk ben je in de toekomst wat voorzichtiger met (of in ieder geval wat meer bewust van) het kiezen van de vorm van de data die je gebruikt.
Nou.. het was geen string en het was wel degelijk een datum echter ik heb de opmaak eerder dan de vergelijking aangepast naar NL. Dat is ook het enige wat ik heb aangepast.
Hoe kunnen wij dit weten als je in je (onvolledige) codefragment niet vertelt wat $date_0, $date_1_2, $date_2_2, $date_3_2 voor waarden bevatten, van wat voor type / klasse ze zijn en waar deze vandaan komen?
Nou.. het was geen string en het was wel degelijk een datum echter ik heb de opmaak eerder dan de vergelijking aangepast naar NL. Dat is ook het enige wat ik heb aangepast.
Ik snap de discussie niet.
De allereerste reactie is van SanThe èn is dè oplossing.
Is hij dan zo slim of... Nou ja, laat ik die zin maar niet afmaken.
Onnodige discussie dit in ieder geval.
Nogmaals SanThe bedankt voor de oplossing.
De rest ook bedankt voor het meedenken.
Santhe geeft de oplossing.
Thomas, Ozzie en ik geven de oorzaak aan.
Zodat je volgende keer wel weet waar het aan ligt.
Santhe vergelijkt namelijk nog steeds strings met elkaar. Dat kan prima bij formaat YYYYMMDDHHIISS, want dat is gewoon een groot nummer.