🚀 go-pugleaf

On Mon, 02 Nov 2009 23:56:11 -0000, Marcin Nowak  
<marcin.j.nowak@gmail.com> wrote:

> On Oct 30, 9:16 am, pakalk <pak...@gmail.com> wrote:
>> On 30 Paź, 08:56, Marek Wywiał <onj...@gmail.com> wrote:
>
>> > 'obsługa' dat jest cudowna, wystawmy sobie fakturkę
>> > <?php
>> >   $t = '2003/02/30';
>> >   var_dump(strtotime($t));
>>
>> > radość księgowej - bezcenna
>>
>> a co wychodzi? Moze format nie taki jak obslugiwany? Co sie wtedy
>> dziwic?
>
> po prostu nie ma 30 lutego. z ciekawosci sprawdz wynik.

var_dump(strtotime('2003/02/32')); # => false
echo strftime("%Y/%m/%d", (strtotime('2003/02/32'))); # 1970/01/01

Nieprzewidywalność i zero intuicyjności to najwidocznie integralna cecha  
pehapa. W tym wypadku bezmyślnie zakłada że każdy miesiąc może mieć do 31  
dni. Z drugiej strony rozpoznaje lata przestępne. Rok 2003 luty miał 29  
dni. PHP po swojemu sobie to interpretuje, więc 2003-02-30 to dla niego to  
samo co 2003-03-01. Raczej mało kto wpadnie na to, że coś takiego się może  
stać. Więc trudno taki błąd wyłapać. Ani wyjątku ani warninga, ani notice,  
kompletnie nic. Faktycznie księgowa się może zdziwić. Nie tylko jak  
uważam, że PHP nie nadaje się do poważnych zastosowań. W nim roi się od  
takiego szeregu nonsensów.

Dla odmiany, jak do problemu podchodzi Ruby:

require 'date'
Date.strptime('2003/02/29', '%Y/%m/%d') # => wyjątek ArgumentError:  
invalid date
Date.strptime('2003/02/28', '%Y/%m/%d') # => => #<Date:  
4905397/2,0,2299161>

Zła data jest złą datą i już. Proste i logiczne. Wyrzuca wyjątek więc  
można to gdzieś wyłapać w wyższej warstwie. Nic się nie prześliźnie. W PHP  
bardzo łatwo przeoczyć mnostwo błędów. Nawet kopanie w logach nie  
gwarantuje (w powyższyzm przypadku nie ma żadnego warninga). To język dla  
masochisty.

-- 
JZ http://blog.zabiello.com