Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:19276 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 98247 invoked by uid 1010); 28 Sep 2005 16:57:24 -0000 Delivered-To: ezmlm-scan-internals@lists.php.net Delivered-To: ezmlm-internals@lists.php.net Received: (qmail 98232 invoked from network); 28 Sep 2005 16:57:24 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 28 Sep 2005 16:57:24 -0000 X-Host-Fingerprint: 212.199.103.105 212.199.103.105.static.012.net.il Received: from ([212.199.103.105:14687] helo=localhost.localdomain) by pb1.pair.com (ecelerity 2.0 beta r(6323M)) with SMTP id ED/55-54476-27BCA334 for ; Wed, 28 Sep 2005 12:57:23 -0400 Message-ID: To: internals@lists.php.net References: <43393A43.4070805@lsces.co.uk> <43397E48.7080107@lsces.co.uk> <43398CB6.9030808@lsces.co.uk> Date: Thu, 29 Sep 2005 19:55:34 +0200 Lines: 44 X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-RFC2646: Format=Flowed; Original X-Posted-By: 212.199.103.105 Subject: Re: [PHP-DEV] timezones & date() breakage From: momo@php.net ("Moshe Doron") It looks like all become relaxed now here but not me. Here in Israel, there is stupid habit to change the DST range almost each year. Should i expect that today's php5.1 date() function 'll give me wrong date next year? If yes, we have here fatal BC break since modern server OS DST data is automatically refreshed, but out of the question the php version on my servers .... the only reasonable solution is separated set of functions as Pierre proposed. Moshe "Derick Rethans" wrote in message news:Pine.LNX.4.62.0509281552110.24804@localhost... > On Wed, 28 Sep 2005, Stanislav Malyshev wrote: > >> DR>>> too because it concides with Fiji and Austria and your Db doesn't >> support >> DR>>> it? >> DR>> >> DR>>I don't see your point here, can you clarify this with a little >> example >> DR>>perhaps? >> >> Well, that's the same problem I had but it would be not IDT, but, say, >> some FDT which has multiple timezones too. Now if you say it would be >> generated from some big TZ database and not just fixed for particular >> case then I guess it would not be a concern. > > Right, of course fixing it for IDT only would be silly :) > > regards, > Derick > > -- > Derick Rethans > http://derickrethans.nl | http://ez.no | http://xdebug.org