On Fri, 30 Sep 2005, Wez Furlong wrote:
> 20 known (and worked-around) bugs are "better" than an unknown
> quantity of unknown bugs.
>
> Remember: it worked "yesterday" but with the minor release it stops working.
> Just because the new version works for you, doesn't mean it isn't
> broken for ot
20 known (and worked-around) bugs are "better" than an unknown
quantity of unknown bugs.
Remember: it worked "yesterday" but with the minor release it stops working.
Just because the new version works for you, doesn't mean it isn't
broken for others :)
Can you honestly guarantee that it's not goi
On Thu, 29 Sep 2005, Andi Gutmans wrote:
> - In Israel the timezone DB changes every year (we start savings time on
> different dates every year depending on the parliament decision).
That is incorrect. That was only upto and including 2004. Since 2005
there is a set-rule for it.
> I see that
>
Hi,
On Thu, 29 Sep 2005 07:00:53 -0700, in php.internals [EMAIL PROTECTED]
(Andi Gutmans) wrote:
>For example, with the date(), having a version (such as 5.1.x) which
>emits a warning and allows to select old behavior via INI.
Again, out of curiousity. What would the impact be for a
developer/u
Quick check so I completely understand where we are:
- In Israel the timezone DB changes every year (we start savings time
on different dates every year depending on the parliament decision).
I see that in your implementation this DB is taken from a table
written in C. Are you saying that this
I completely agree here, and it was only because I was sure that it
was only an implementation and not a functionality change that I
agreed for it to be commited.
We could do something like NIO in Java, and have newr APIs for this
functionality, this way people who want to use the new APIs win (
We know you want to break as many apps as possible, but many of us
prefer to be more accomodating to the large amount of apps out there
and do it in a gradual and controlled way.
For example, with the date(), having a version (such as 5.1.x) which
emits a warning and allows to select old behavio
Call it FUD if you like; I call it "sleeping easier at night". Like
it or not, PHP is big enough now that these things have become
critical points for larger businesses. To completely replace the
default implementation of a core function with something new is quite
a risk when it's not had enough
The "masses" don't have to update. The old broken date() is still
in PHP 4.4.0 and PHP 5.0.x.
Please stop the BC fud, this is not about a bugfix release but
something a bit bigger thing.
One other solution: we can always change PHP_5_1 to PHP_6
and do all other nice "BC"
Andi Gutmans wrote:
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 whi
On Wed, 28 Sep 2005, Andi Gutmans wrote:
> 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 tha
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
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
s" <[EMAIL PROTECTED]>
Cc: "PHP Developers Mailing List"
Sent: Wednesday, September 28, 2005 1:59 PM
Subject: Re: [PHP-DEV] timezones & date() breakage
> DR>>I think this shoul adequately solve the problems that you encountered.
>
> Thanks for finding a way
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
;
Sent: Wednesday, September 28, 2005 1:54 PM
Subject: Re: [PHP-DEV] timezones & date() breakage
> 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 b
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
ECTED]>
Cc:
Sent: Wednesday, September 28, 2005 1:33 PM
Subject: Re: [PHP-DEV] timezones & date() breakage
> 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
&g
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
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
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.
--
Stanislav Malyshev, Zend Products Engineer
[EMAIL PROTECTED] http://www.zend.com/ +972-3-6139665 ext.115
On Wed, 28 Sep 2005 00:08:37 +0300, in php.internals [EMAIL PROTECTED]
(Zeev Suraski) wrote:
>The old code didn't have IDT hardcoded, therefore all of the sarcasm and
>cynicism around the validy of the code are completely baseless. It was
>using a system setting, which I suspect a lot of applic
At 16:49 27/09/2005, Stanislav Malyshev wrote:
Provided that date() worked fine before, I see absolutely no reason to
require such complex things now - for doing the same basic things as
before. If you need to do andavnced things - that's OK, require advanced
configuration, but simple things shou
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 local time ;)
I am starting to get an impression that you r
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 most sources
I've tried to access seem to be limited to?
I
On Tue, 27 Sep 2005, Lester Caine wrote:
> Derick Rethans wrote:
>
> > gmdate() is for that, date() should always show a local time. The new
> Local to who ;)
>
> > code (which is unfortunately not enabled), allows you do do all kinds of
> > timezone manipulation. Feel free to test it by settin
Derick Rethans wrote:
gmdate() is for that, date() should always show a local time. The new
Local to who ;)
code (which is unfortunately not enabled), allows you do do all kinds of
timezone manipulation. Feel free to test it by setting your CFLAGS to
-DEXPERIMENTAL_DATE_SUPPORT and use the n
Stanislav Malyshev wrote:
LC>>There is absolutely no reason that date() should supply anything other
LC>>than the current UTC time. It is the only thing that is actually
LC>>RIGHT!
Sure there is. If you want to display what time is it now, you don't need
UTC. Do you have your watch in UTC an
On Tue, 27 Sep 2005, Lester Caine wrote:
> Derick Rethans wrote:
>
> > >I'm coming in late here - but being in the middle of trying to configure a
> > >system to provide calendars across time and daylight saving zones, I've
> > >been deep in this! I have no problem with the time AT THE SERVER! Wh
LC>>There is absolutely no reason that date() should supply anything other
LC>>than the current UTC time. It is the only thing that is actually
LC>>RIGHT!
Sure there is. If you want to display what time is it now, you don't need
UTC. Do you have your watch in UTC and your wall clock in your hom
Derick Rethans wrote:
I'm coming in late here - but being in the middle of trying to
configure a system to provide calendars across time and daylight
saving zones, I've been deep in this! I have no problem with the time
AT THE SERVER! What I need to know is what daylight saving zone the
clien
DR>>You are perhaps not aware that the timezone databases on many servers
DR>>are so incredibly out of date, are you? And your "system settings" are
DR>>not working, read the mails once more why. I am not going to repeat it
DR>>again.
My settings are working perfectly well, thank you. All and e
IA>>The problem before was that there was no 1 certain date setting. For
Oh, but there is. It is "use system settings". That is the date setting I
am looking for, and that's what I will be using in 99% of the cases -
because apps I dela with don't need multiple timezone support on single
server
On Tue, 27 Sep 2005, Stanislav Malyshev wrote:
> DR>>There is but I was not allowed to enable those functions in PHP 5.1. If
> DR>>you compile with -DEXPERIMENTAL_DATE_SUPPORT, you have a function
> DR>>timezone_identifiers_list() which returns a list with all the support
> DR>>settings. The fu
DR>>There is but I was not allowed to enable those functions in PHP 5.1. If
DR>>you compile with -DEXPERIMENTAL_DATE_SUPPORT, you have a function
DR>>timezone_identifiers_list() which returns a list with all the support
DR>>settings. The function timezone_abbreviations_list() returns the known
On Tue, 27 Sep 2005, 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
> taking a step backwards in terms of ma
On Tue, 27 Sep 2005, Stanislav Malyshev wrote:
> IA>>This "incantation" is the standard name for your timezone across most
> IA>>systems. Out of curiosity I've just tried "IDT" timezone on 3 machines
> IA>>(Linux, FreeBSD and OpenSolaris) neither of'em supported it. However,
> IA>>they all support
Stas,
The problem before was that there was no 1 certain date setting. For
example on your machine IDT worked, on mine "Israel/Tel Aviv" and for
Derick Asia/Tel_Aviv was the working name for the same timezone. So when
designing an app to run on different servers the developer will have to
find out
JT>>Yeah, keep using PHP 4.
That's an excellent suggestion. Thank you very much.
--
Stanislav Malyshev, Zend Products Engineer
[EMAIL PROTECTED] http://www.zend.com/ +972-3-6139665 ext.115
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/uns
IA>>This "incantation" is the standard name for your timezone across most
IA>>systems. Out of curiosity I've just tried "IDT" timezone on 3 machines
IA>>(Linux, FreeBSD and OpenSolaris) neither of'em supported it. However,
IA>>they all supported "Israel/Tel Aviv", which is the real name for your
IA
DR>>Not really. You really do need to make the configuration setting as
DR>>none of the code currently relies on any OS, and we should definitely
DR>>keep it like that. Now, what we can do is document the list of
DR>>setttings that you can use as timezone.
The problem is I don't think there's e
On Tue, 27 Sep 2005, Stanislav Malyshev wrote:
I propose to make some mode to date() that would allow falling back to old
functionality if I do not use new improved capabilities. Meaning, if I do
not set new configurations, it would work as it did in PHP4. Is this
possible?
Yeah, keep usin
Stanislav Malyshev wrote:
> DR>>Using a timezone abbreviation is a bad thing anyway. Your timezone is
>
> Breaking working applications is a bad thing.
>
> DR>>"Isreal/Tel Aviv" and *currently* your abbreviation is IDT. IDT is not a
> DR>>timezone, it is the description of the period in which
On Tue, 27 Sep 2005, Stanislav Malyshev wrote:
> There's no any sarcasm - I really do want date() to work like it did
> before. It is OK to give additional capability for timezone changing, etc.
> - but I don't see why this should be at the cost of making previously
> working code now require a
DR>>> find out the incantation that your library will agree to accept, right?
DR>>> And if I don't find one, bad luck - no date() anymore. So how that's an
DR>>> improvement? Can I get back the unimproved working one?
DR>>
DR>>Please keep all the sarcasm for yourself.
There's no any sarcasm - I
On Tue, 27 Sep 2005, Stanislav Malyshev wrote:
> So, in order for my application to continue working I should go and try to
> find out the incantation that your library will agree to accept, right?
> And if I don't find one, bad luck - no date() anymore. So how that's an
> improvement? Can I ge
DR>>Using a timezone abbreviation is a bad thing anyway. Your timezone is
Breaking working applications is a bad thing.
DR>>"Isreal/Tel Aviv" and *currently* your abbreviation is IDT. IDT is not a
DR>>timezone, it is the description of the period in which you use DST in
DR>>combination with I
On Tue, 27 Sep 2005, Lester Caine wrote:
> I'm coming in late here - but being in the middle of trying to
> configure a system to provide calendars across time and daylight
> saving zones, I've been deep in this! I have no problem with the time
> AT THE SERVER! What I need to know is what dayli
Derick Rethans wrote:
http://no2.php.net/manual/en/function.date-default-timezone-get.php
says:
This functions returns the default timezone, using the
following "guess" order:
* The timezone set using the date_default_timezone_set()
function (if any)
* The
On Tue, 27 Sep 2005, Stanislav Malyshev wrote:
> The timezone is named IDT currently, but the problem is not in this - the
> problem is in "we can add it". OK, we add this one - how many ones out
> there we didn't add yet? So we will be fixing it for years and still get
> it not work in some pl
DR>>Sure you can, you just set the timezone yourself with the
DR>>date.timezone setting. If you had e_strict errors turned on, you would
DR>>have seen a warning about this.
Not so easy. Tried that - it complains it doesn't know my timezone.
DR>>What is the timezone abbreviation (you can not cal
On Tue, 27 Sep 2005, Stanislav Malyshev wrote:
> While everything worked just fine before, I can not use date() function
> anymore.
Sure you can, you just set the timezone yourself with the date.timezone
setting. If you had e_strict errors turned on, you would have seen a
warning about this.
>
I see that in PHP5.1 the handling of date() was changed, and now I see
that at least on my machine (and all machines we have, actually) all
date() functions suddently started to return dates in UTC and spit out
warnings.
I understand that it was due to some improvement of timezone
handling, b
100 matches
Mail list logo
