I agree, and we should currently have both so that we can migrate
users to Derick's new code. Derick, I think you need to return the
support for the old functionality (it can probably be done quite
easily by taking the old code as-is). We should then have an INI
option which selects between th
Bah, hit send too soon...
On 9/28/05, Wez Furlong <[EMAIL PROTECTED]> wrote:
> This way we get the "best" of both worlds; BC is preserved for the
> masses of existing code and we get more QA on the new implementation
from early adopters
> ready for going production with the new code in PHP 6.
-
I agree; date() in 5.1 should default to the older "broken" code for
BC and have a toggle for the new stuff. We could also issue a
deprecation notice to warn people about a future move to the new code
in PHP 6.
This way we get the "best" of both worlds; BC is preserved for the
masses of existing
On Wed, 28 Sep 2005 09:01:12 -0700
[EMAIL PROTECTED] (Rasmus Lerdorf) wrote:
> This discussion has been interesting. ;)
>
> These sorts of problems have come up many times during the course of
> PHP development. Things that were implemented to solve a very
> specific local problem ended up caus
When I agreed to commit this for PHP 5.1, Derick promised that this
was going to completely keep BC. That is obviously not happening.
While I appreciate his efforts, I think as with the reference change,
this will cause much more widespread pain than we can even imagine.
Without being an expert
Hello Edin,
cool, thanks!
marcus
Wednesday, September 28, 2005, 10:52:00 PM, you wrote:
> http://ftp.emini.dk/pub/php/win32/php6/
> Edin
> Marian Kostadinov wrote:
>> I'd like to do some tests of the new __toString functionality but it
>> seems that it is committed only in PHP6-CVS branc
http://ftp.emini.dk/pub/php/win32/php6/
Edin
Marian Kostadinov wrote:
I'd like to do some tests of the new __toString functionality but it
seems that it is committed only in PHP6-CVS branch. Is there a way to
get a windows binary snapshot for this branch?
--
PHP Internals - PHP Runtime Deve
On Sep 28, 2005, at 12:46 PM, Derick Rethans wrote:
On Wed, 28 Sep 2005, George Schlossnagle wrote:
Carrying on the stupid questions: Is it possible to make a better
'guess' in
the case that there are name-collisions or missing names and no
ini setting is
set? Perhaps something like dete
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
au
On Wed, 28 Sep 2005, George Schlossnagle wrote:
> Carrying on the stupid questions: Is it possible to make a better 'guess' in
> the case that there are name-collisions or missing names and no ini setting is
> set? Perhaps something like determining the current offset from UTC and just
> choosing
On Sep 28, 2005, at 8:54 AM, Derick Rethans wrote:
On Wed, 28 Sep 2005, Steph wrote:
This is probably a stupid question, but why isn't there a default
setting?
And why can't the missing default setting be set by the system date
() data?
That's exactly what I was trying to do, except th
This discussion has been interesting. ;)
These sorts of problems have come up many times during the course of PHP
development. Things that were implemented to solve a very specific
local problem ended up causing grief when the scope of PHP grew. Think
of things like magic_quotes_gpc and case-in
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 woul
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 to
Pierre wrote:
There is no safe solution but using a separate set of functions until
6.0. I tried too many times to explain how complex can be date/time
problems and trying to fix them in a minor release is the best bad idea
of the year.
I'm with you on that, but since UNICODE is now becoming m
Hi,
Andreas Korthaus wrote:
Lukas Smith wrote:
I dont see a pressing need for an OO API and I also dont think that
PHP internal API's should one by one be moved over to an OO interface
either.
IMO date is a very good example where a nice OO API is very useful -
particularly for people wit
Stanislav Malyshev wrote:
LC>>Stanislav - DISPLAYING local time only applies to the local site - when you
LC>>are logging into an Australian machine the local time of that machine is not
LC>>a lot of use. But *IF* I want to compare - say - bid times between an
Just think about what you are tell
hmm but if Derick's picking up the name of the tz the way he suggested and
printing it as part of an E_STRICT we'll soon get clear reports of any
exceptions to the rule.
- Original Message -
From: "Stanislav Malyshev" <[EMAIL PROTECTED]>
To: "Derick Rethans" <[EMAIL PROTECTED]>
Cc: "PHP D
On Wed, 28 Sep 2005, Steph wrote:
>
> > I wouldn't call it broken, just less inituitive. But besides that point,
> > I looked at some data and have a patch that allows the timezone guessing
> > code to also check against the GMT offset, and not only the
> > abbreviation. This means that with thes
On Wed, 28 Sep 2005 15:02:38 +0200 (CEST)
[EMAIL PROTECTED] (Derick Rethans) wrote:
> I think that's a very marginal problem, perhaps a problem for 0.1% of
> the world population. I think we can live with that.
Is it the same 0.1% as in 5.0.5?
--
PHP Internals - PHP Runtime Development Mailin
On Wed, 28 Sep 2005 15:59:45 +0300 (IDT)
[EMAIL PROTECTED] (Stanislav Malyshev) wrote:
> DR>>I think this shoul adequately solve the problems that you
> DR>>encountered.
>
> Thanks for finding a way to solve it at least for this example. But I
> am still concerned that it would solve the problem
On Wed, 28 Sep 2005, Stanislav Malyshev wrote:
> DR>>I think this shoul adequately solve the problems that you encountered.
>
> Thanks for finding a way to solve it at least for this example. But I am
> still concerned that it would solve the problem for me, but what if I
> install it somewhere
> I wouldn't call it broken, just less inituitive. But besides that point,
> I looked at some data and have a patch that allows the timezone guessing
> code to also check against the GMT offset, and not only the
> abbreviation. This means that with these DB entries:
>
> { "idt", 1, -HOUR (
DR>>I think this shoul adequately solve the problems that you encountered.
Thanks for finding a way to solve it at least for this example. But I am
still concerned that it would solve the problem for me, but what if I
install it somewhere in Finland or Australia and their TZ is not working
too
So you're saying this issue's going to be history by the time 5.1 is due for
release?
- Original Message -
From: "Derick Rethans" <[EMAIL PROTECTED]>
To: "Steph" <[EMAIL PROTECTED]>
Cc: "Stanislav Malyshev" <[EMAIL PROTECTED]>;
Sent: Wednesday, September 28, 2005 1:54 PM
Subject: Re: [PH
On Wed, 28 Sep 2005, Steph wrote:
> This is probably a stupid question, but why isn't there a default setting?
> And why can't the missing default setting be set by the system date() data?
That's exactly what I was trying to do, except the fall back
abbreviations (IDT) didn't all link to timezon
S>>This is probably a stupid question, but why isn't there a default setting?
Because there's no default timezone - everybody has different one. I would
be very happy if it used system settings once the ini value is not set -
actually, it would then be no problem at all with new date extension a
On Wed, 28 Sep 2005, Stanislav Malyshev wrote:
> DR>>But you do need UTC somewhere, as *all* date code (OS, applications)
> DR>>use UTC timestamps to calculate the current time.
>
> So? They are able to use it transparently without requiring me to do any
> special configuration for each applica
LS>>Please Stas .. I was talking about a long term vision. Why do you have to
LS>>insist drawing up horror scenarios that are unrelated to my comments? While
LS>>this may be an effective strategy in politics I find it unnecessary inside a
LS>>technical discussion on open source software.
What is s
Lukas Smith wrote:
I dont see a pressing need for an OO API and I also dont think that PHP
internal API's should one by one be moved over to an OO interface either.
IMO date is a very good example where a nice OO API is very useful -
particularly for people with advanced needs of date/timezon
This is probably a stupid question, but why isn't there a default setting?
And why can't the missing default setting be set by the system date() data?
- Original Message -
From: "Stanislav Malyshev" <[EMAIL PROTECTED]>
To: "Lukas Smith" <[EMAIL PROTECTED]>
Cc:
Sent: Wednesday, September
Stanislav Malyshev wrote:
LS>>Now the new code does cause problems for some (certainly not a majority of
LS>>people) and this needs to be taken into account. However if these people do
I wonder how do you know it's not a majority? Almost nobody is using 5.1
in production now, but once it's out
Pierre wrote:
And the question is more about delaying 5.1.0 or not. I doubt it is a
possible to delay again 5.1.0. There is thousands of critical fixes in
there, and many people are waiting for them since months. Sadly.
I agree ... PHP 5.1.0 should not be delayed any longer. There are enough
LS>>Now the new code does cause problems for some (certainly not a majority of
LS>>people) and this needs to be taken into account. However if these people do
I wonder how do you know it's not a majority? Almost nobody is using 5.1
in production now, but once it's out you are bound to get a rain
On Wed, 28 Sep 2005 14:18:29 +0200
[EMAIL PROTECTED] (Lukas Smith) wrote:
> Again timing is a separate issue, just talking about the long term
> here ..
Long term problems are not fixed in minor releases. Or we will have
Unicode in 5.2.
> On one side you have people writing single timezone appli
Stanislav Malyshev wrote:
I don't see any need to force users into anything they don't need just
because you seem to like the new code. Users don't care how much you love
the code, they care if it works - and now it does not, at least not for
the atsk of printing current date with date() call.
Stanislav,
You are absolutely right. date() has always worked just fine and 100%
reliable. Maybe it wasn't suitable for certain applications, but for others
it has been very suitable. If it is decided that the date extension will be
replaced by new behavior and will break older applications, I thi
LS>>You honestly claim that the current code makes it possible to write portable
LS>>code? Anyone who has ever tried to write a calendar app in PHP will tell you
LS>>that timezone handling is beyond subpar in PHP.
I wrote "did exactly what I wanted it to do - show current time on the
machine". Ye
Well, if PHP integers are turned into int64 datatypes, there'd be more room
to operate for dates (I read in Derick's PDF that 2^31 presents problems,
and therefor abstraction by an object class helps out). Then an OO datatype
for dates wouldn't be needed.
But on the other hand, I can't say I'd min
I'd like to do some tests of the new __toString functionality but it
seems that it is committed only in PHP6-CVS branch. Is there a way to
get a windows binary snapshot for this branch?
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Stanislav Malyshev wrote:
LS>>It seems evident that the old magic never worked reliably exactly for those
LS>>people that are now seemingly adversly affected by the current changes. Its
It doesn't seem evident to me. For me it worked flawlessly and did
exactly what I wanted it to do - show curr
Edin Kadribasic wrote:
I dont see a pressing need for an OO API and I also dont think that PHP
internal API's should one by one be moved over to an OO interface either.
I think the point is to have date() working as it was, and have a *new*
extension for all the fancy stuff (including OO).
LS>>It seems evident that the old magic never worked reliably exactly for those
LS>>people that are now seemingly adversly affected by the current changes. Its
It doesn't seem evident to me. For me it worked flawlessly and did
exactly what I wanted it to do - show current time on the machine in t
Lukas Smith wrote:
> Andreas Korthaus wrote:
>
>> People needing the new features (like me) would be happy if old
>> date/time behave the same as before 5.1, and if there is a new OO
>> interface for the new extension.
>
>
> I dont see a pressing need for an OO API and I also dont think that PHP
Andreas Korthaus wrote:
People needing the new features (like me) would be happy if old
date/time behave the same as before 5.1, and if there is a new OO
interface for the new extension.
I dont see a pressing need for an OO API and I also dont think that PHP
internal API's should one by one
So it seems to me we have 2 issues here:
1) timing
2) code duplication or not
It seems evident that the old magic never worked reliably exactly for
those people that are now seemingly adversly affected by the current
changes. Its just that what worked by chance may not work anymore and
vice v
Derick Rethans wrote:
[...], if you have any idea on how to
make things better, please step forward. I already spoke with the doc
folks how to document all the timezones that we now support.
I've learned about the limitations of the old date/time functions some
time ago, so I had to impleme
> Again and for the record in this thread, I told you and here many
> times, the only safe way is to develop the new features in a separate
> code base (ext/date was planned to be used for this exact purpose
> before you decided to move your code there). A separate code base is
> the only way to ke
On Wed, 28 Sep 2005 09:37:14 +0200 (CEST)
[EMAIL PROTECTED] (Derick Rethans) wrote:
> On Wed, 28 Sep 2005, Zeev Suraski wrote:
>
> > So far, except for meaningless purism, I haven't seen a single real
> > reason for the fact that a working application suddenly stopped
> > working.
>
> I'm quit
LC>>Stanislav - DISPLAYING local time only applies to the local site - when you
LC>>are logging into an Australian machine the local time of that machine is not
LC>>a lot of use. But *IF* I want to compare - say - bid times between an
Just think about what you are telling me. I say "with new code
Derick Rethans wrote:
On Wed, 28 Sep 2005, Stanislav Malyshev wrote:
LC>>> UTC. Do you have your watch in UTC and your wall clock in your home in
LC>>> UTC?
LC>>
LC>>ACTUALLY - all the server clocks are set to GMT - that way I know who ever
LC>>enters data, the timestamp is always correct,
DR>>But you do need UTC somewhere, as *all* date code (OS, applications)
DR>>use UTC timestamps to calculate the current time.
So? They are able to use it transparently without requiring me to do any
special configuration for each application - they just go out and display
the right date. Only
DR>>Now, besides the whining and bickering, if you have any idea on how to
DR>>make things better, please step forward. I already spoke with the doc
Yes, I have an idea. Restore old date() function while keeping new one.
--
Stanislav Malyshev, Zend Products Engineer
[EMAIL PROTECTED] http://w
DR>>It's also what you would see in India right now - and they mean two
DR>>totally different things.
OK, but if I would run 'date' from command line here and in India, in both
cases I would have right date displayed. If I run 'date()' from PHP 5.1,
it would in both cases fail and display UTC d
On Wed, 28 Sep 2005, Zeev Suraski wrote:
> So far, except for meaningless purism, I haven't seen a single real
> reason for the fact that a working application suddenly stopped
> working.
I'm quite tired of this purism argument. You seem to invoke that
whenever somebody wants to make some form
On Tue, 27 Sep 2005, Lester Caine wrote:
> Derick Rethans wrote:
>
> > >I am building a calendar that requires the correct daylight saving entries
> > >historically and ongoing. Will the new system support this or is it purely
> > >designed to provide the current daylight saving setting - which m
On Wed, 28 Sep 2005, Stanislav Malyshev wrote:
> LC>>> UTC. Do you have your watch in UTC and your wall clock in your home in
> LC>>> UTC?
> LC>>
> LC>>ACTUALLY - all the server clocks are set to GMT - that way I know who ever
> LC>>enters data, the timestamp is always correct, what ever their lo
On Wed, 28 Sep 2005, Stanislav Malyshev wrote:
> PB>>Just out of curiousity of the scope of this issue... where did the
> PB>>string "IDT" come from in the first place?
>
> That's what I see as a timezone what I run 'date' from command line.
It's also what you would see in India right now - and
On Tue, 27 Sep 2005 09:58:11 -0400
[EMAIL PROTECTED] (Ilia Alshanetsky) wrote:
> Yes, initially there will be some short-term pain in converting
> existing apps, but for the long term it'll provide a robust and
> portable solution. If we add "legacy" flag or INI setting, I feel
> that we'd be tak
59 matches
Mail list logo
