Hei,
I wrote up a little document about how I want to implement the date and
timezone "class"es - although I'm not planning any OO methods. I'm just
wrapping the timelib_time and timelib_tzinfo structures in an
object. Let me know what you think.
Derick
On Thu, 7 Jul 2005 23:10:16 +0200 (CEST)
derick@php.net (Derick Rethans) wrote:
Hei,
I wrote up a little document about how I want to implement the
date and timezone "class"es - although I'm not planning any OO
methods. I'm just wrapping the timelib_time and timelib_tzinfo
structures in an object. Let me know what you think.
The functions related to the timezone (fetching, offset,...) sounds
good to me.
For the rest, I already did it since one and half year for the base.
The other are only duplicated with current function. This is maybe
useless. The worst being to rely on strtotime to manipulate date,
this is maybe human readable (understandable is another
question ;), but it is slooow, and the best way to hell for non
english application.
When we talked about a common object or resource in PHP, based on
what you did not read in pecl/date, it was about real transparency
throug methods able to work with date/time values.
I suggest to make this enhancement in pecl/date. All the base is
already here.
This is anyway a task post 5.1, for now your implementation has to
be bullet proofed until that (thinking about timezone and some
function like week number or other sources of annoyance).
Regards,
--Pierre
The other are only duplicated with current function. This is maybe
useless. The worst being to rely on strtotime to manipulate date,
this is maybe human readable (understandable is another
question ;), but it is slooow, and the best way to hell for non
english application.
I've been thinking about this, but the other way I could come up with is
by passing a complex array instead of the textual description, something
like:
$modi = array('month' => 1);
But then does that mean: next month, month 1 (january) or "first
month"... I'm open here for other solutions, I just didn't find a better
one that using strtotime() equivalent modifiers here. I also think that
consistency is good :)
When we talked about a common object or resource in PHP, based on
what you did not read in pecl/date, it was about real transparency
throug methods able to work with date/time values.I suggest to make this enhancement in pecl/date. All the base is
already here.
Right, one of the reasons that I made it an object, you can easily
extend it there.
This is anyway a task post 5.1, for now your implementation has to
be bullet proofed until that (thinking about timezone and some
function like week number or other sources of annoyance).
Week numbers work fine? Do you see a bug? If so, send me a reproducable
script.
Derick
--
Derick Rethans
http://derickrethans.nl | http://ez.no | http://xdebug.org
Hey Derick,
If you're just wrapping the date type with a class, I don't see why it
shouldn't be a resource. It'd give you the same thing but would be easier
to implement (unless I'm missing something).
I realize you personally aren't fond of OO but it actually would work very
nicely with a Date class. I'm not talking about OO as in over-architecting
and having a huge hierarchy but just having easy to use methods on the
Date/TimeZone classes (one simple level).
It would look the following:
$timeZone->getName();
vs.
date_timezone_get($date);
$date->getOffset();
vs.
date_offset_get($date);
Personally, unrelated to OO I think it's a nicer and cleaner way of
exposing such an API. It would also make it easier for some of the other
new extensions like SimpleXML, SOAP, PDO , etc. to take advantage of it
when exposing data types.
I think this should be seriously considered. I'll be happy to work with you
on this if it makes sense to you and others.
I think that this functionality is best to be developed in parallel to 5.1.
As it would be new unrelated functionality, I think we could introduce it
in 5.1.x after 5.1.0 is out and once everyone feels comfortable with it. I
don't think rushing it into 5.1.0 is a good idea especially if my feedback
is considered.
Andi
At 11:10 PM 7/7/2005 +0200, you wrote:
Hei,
I wrote up a little document about how I want to implement the date and
timezone "class"es - although I'm not planning any OO methods. I'm just
wrapping the timelib_time and timelib_tzinfo structures in an
object. Let me know what you think.Derick
On Thu, 07 Jul 2005 16:56:51 -0700
andi@zend.com (Andi Gutmans) wrote:
Hey Derick,
If you're just wrapping the date type with a class, I don't see
why it shouldn't be a resource. It'd give you the same thing but
would be easier to implement (unless I'm missing something).
I realize you personally aren't fond of OO but it actually would
work very nicely with a Date class. I'm not talking about OO as
in over-architecting and having a huge hierarchy but just having
easy to use methods on the Date/TimeZone classes (one simple
level).It would look the following:
$timeZone->getName();
vs.
date_timezone_get($date);$date->getOffset();
vs.
date_offset_get($date);
I fully agree with that. I'm not a OO fanatic (meaning using OO for
every little variable around) but date/time values are perfect
candidate for objects (see pecl/date again for example).
Object properties fetching are fast if well implemented. They allow
to easily create loops and other steped operations.
This kind of API was also why I asked to add TZ aliases support.
Having 2 tables and a double lookup is not really a good idea ;).
Personally, unrelated to OO I think it's a nicer and cleaner way
of exposing such an API. It would also make it easier for some of
the other new extensions like SimpleXML, SOAP, PDO , etc. to take
advantage of it when exposing data types.
This is what I talk about when I say a common Date object in php.
Derick exported the headers on my demand, this is a good first step.
I think this should be seriously considered. I'll be happy to
work with you on this if it makes sense to you and others.
I think that this functionality is best to be developed in
parallel to 5.1. As it would be new unrelated functionality, I
think we could introduce it in 5.1.x after 5.1.0 is out and once
everyone feels comfortable with it. I don't think rushing it into
5.1.0 is a good idea especially if my feedback is considered.
If the 5.1.x that will have that is not too close from 5.1 (new job
on 8th august...), I have some really good additions, they are
nearly all unit tested, remains some doc ;). I will commit part of
it in the next weeks (minus TZ as it conflicts with Derick's one...)
As I said in another post, I do not have either the time or the
motivations to port everything to ext/date. I partially disagree on
some design choices and pecl/date has been totally ignored by
Derick, that does not help :).
Having the current code in 5.1.0 for some weeks will help to fix it
and find possible issues, errors, or needs requested by extension
developers. Then we can safely add this new API as experimental for
the 1st release. Once everyone agrees (or no one complained), we
will freeze it.
Regards,
--Pierre
[snip]
This is what I talk about when I say a common Date object in php.
Derick exported the headers on my demand, this is a good first step.
I agree that it would be a great idea to have a common Date object in PHP. And
since most of it is already implemeted by the new timelib and the existing
object code in PECL/date I see no reason not merge that in core date module.
I would love to be able to do something like this:
$d = new Date(time());
$d->month++;
$d->print("Y-m-d"); // date() equiv.
And implement all other datetime functions in similar matter.
Edin
I would love to be able to do something like this:
$d = new Date(time());
$d->month++;
$d->print("Y-m-d"); //date()equiv.
Adding methods is no problem, that's what you get for free anyway, I
just think that $d->month is too much magic, and not reproducable in non
OO. (Also, passing a timestamp with time() is not always working,
because of windows' limitations with it, that's the reason why I made it
a string, or empty in case you want to use current time).
Derick
Derick Rethans
http://derickrethans.nl | http://ez.no | http://xdebug.org
On Fri, 8 Jul 2005 14:31:14 +0200 (CEST)
Derick Rethans derick@php.net wrote:
I would love to be able to do something like this:
$d = new Date(time());
$d->month++;
$d->print("Y-m-d"); //date()equiv.Adding methods is no problem, that's what you get for free
anyway, I just think that $d->month is too much magic, and not
reproducable in non OO. (Also, passing a timestamp withtime()is
not always working, because of windows' limitations with it,
that's the reason why I made it a string, or empty in case you
want to use current time).
for the current time, it's fine. For example getting the next
monday is pretty easy using this way.
Properties are not magic. Thier behiavors have to be well
documented. And how they work discussed.
I talked a bit with Derick on IRC. I will take some times to
finalize the specifications and put them online. We can then have a
document to talk about. Not like I like to talk endlessly but there
is issues we have to agree on before any implementation. Expect it
over the weekend.
Regards,
--Pierre
Hello Derick,
Friday, July 8, 2005, 2:31:14 PM, you wrote:
I would love to be able to do something like this:
$d = new Date(time());
$d->month++;
$d->print("Y-m-d"); //date()equiv.
Adding methods is no problem, that's what you get for free anyway, I
just think that $d->month is too much magic, and not reproducable in non
OO.
I wouldn't care for non oo here. And instead pretty much appreciate such
stuff since it'd heavliy simplify working on calendar tools and still
have nice readable code.
--
Best regards,
Marcus mailto:mail@marcus-boerger.de
Can we please wrap up the whole OO/non-OO discussion and just fix the
damn ext/date so that it works as advertised? The rest can be done
later. Let's not hold up RC1 unless really necessary.
-Andrei
Hello Derick,
Friday, July 8, 2005, 2:31:14 PM, you wrote:
I would love to be able to do something like this:
$d = new Date(time());
$d->month++;
$d->print("Y-m-d"); //date()equiv.Adding methods is no problem, that's what you get for free anyway, I
just think that $d->month is too much magic, and not reproducable in
non
OO.I wouldn't care for non oo here. And instead pretty much appreciate
such
stuff since it'd heavliy simplify working on calendar tools and still
have nice readable code.--
Best regards,
Marcus mailto:mail@marcus-boerger.de
Hello Andrei,
++++++++1
Monday, July 11, 2005, 7:16:45 PM, you wrote:
Can we please wrap up the whole OO/non-OO discussion and just fix the
damn ext/date so that it works as advertised? The rest can be done
later. Let's not hold up RC1 unless really necessary.
-Andrei
Hello Derick,
Friday, July 8, 2005, 2:31:14 PM, you wrote:
I would love to be able to do something like this:
$d = new Date(time());
$d->month++;
$d->print("Y-m-d"); //date()equiv.Adding methods is no problem, that's what you get for free anyway, I
just think that $d->month is too much magic, and not reproducable in
non
OO.I wouldn't care for non oo here. And instead pretty much appreciate
such
stuff since it'd heavliy simplify working on calendar tools and still
have nice readable code.
On Mon, 11 Jul 2005 10:16:45 -0700
Andrei Zmievski andrei@gravitonic.com wrote:
Can we please wrap up the whole OO/non-OO discussion and just fix
the damn ext/date so that it works as advertised? The rest can be
done later. Let's not hold up RC1 unless really necessary.
It's not a stopping for 5.1. This is not going to be in 5.1. We
already agreed on that :)
--Pierre
On Mon, 11 Jul 2005 10:16:45 -0700
Andrei Zmievski andrei@gravitonic.com wrote:Can we please wrap up the whole OO/non-OO discussion and just fix
the damn ext/date so that it works as advertised? The rest can be
done later. Let's not hold up RC1 unless really necessary.It's not a stopping for 5.1. This is not going to be in 5.1. We
already agreed on that :)
We did not. I implemented my specs now, including OO methods. Updated
ones are attached.
Derick
--
Derick Rethans
http://derickrethans.nl | http://ez.no | http://xdebug.org
Derick Rethans wrote:
On Mon, 11 Jul 2005 10:16:45 -0700
Andrei Zmievski andrei@gravitonic.com wrote:Can we please wrap up the whole OO/non-OO discussion and just fix
the damn ext/date so that it works as advertised? The rest can be
done later. Let's not hold up RC1 unless really necessary.It's not a stopping for 5.1. This is not going to be in 5.1. We
already agreed on that :)We did not. I implemented my specs now, including OO methods. Updated
ones are attached.
I agree with Andrei that we should not hold up 5.1 release with
ext/date. We should IMHO release 5.1 with the working replacements of
broken existing functions. Having datetime stuff working independent of
the OS is an achievement in itself.
As for the additional functionality I belive that more effort should be
made to come up with a nice API for handling date/time. Pecl/date is a
very good starting point in this direction and the effort that has been
made there should not be wasted.
As I said, it is the best in my oppinion to leave this for after 5.1
release.
Edin
On Mon, 11 Jul 2005 10:16:45 -0700
Andrei Zmievski andrei@gravitonic.com wrote:Can we please wrap up the whole OO/non-OO discussion and just fix
the damn ext/date so that it works as advertised? The rest can be
done later. Let's not hold up RC1 unless really necessary.It's not a stopping for 5.1. This is not going to be in 5.1. We
already agreed on that :)We did not. I implemented my specs now, including OO methods. Updated
ones are attached.
Patch is here:
http://files.derickrethans.nl/patches/date-2005-07-12.diff.txt
Also fixes a bug parsing 11Oct and adds some constants with commonly
used formats.
Derick
--
Derick Rethans
http://derickrethans.nl | http://ez.no | http://xdebug.org
I think what makes most sense is for you two to work together on this.
Again, I am more than happy to contribute.
Andi
At 02:17 AM 7/8/2005 +0200, Pierre-Alain Joye wrote:
On Thu, 07 Jul 2005 16:56:51 -0700
andi@zend.com (Andi Gutmans) wrote:Hey Derick,
If you're just wrapping the date type with a class, I don't see
why it shouldn't be a resource. It'd give you the same thing but
would be easier to implement (unless I'm missing something).
I realize you personally aren't fond of OO but it actually would
work very nicely with a Date class. I'm not talking about OO as
in over-architecting and having a huge hierarchy but just having
easy to use methods on the Date/TimeZone classes (one simple
level).It would look the following:
$timeZone->getName();
vs.
date_timezone_get($date);$date->getOffset();
vs.
date_offset_get($date);I fully agree with that. I'm not a OO fanatic (meaning using OO for
every little variable around) but date/time values are perfect
candidate for objects (see pecl/date again for example).Object properties fetching are fast if well implemented. They allow
to easily create loops and other steped operations.This kind of API was also why I asked to add TZ aliases support.
Having 2 tables and a double lookup is not really a good idea ;).Personally, unrelated to OO I think it's a nicer and cleaner way
of exposing such an API. It would also make it easier for some of
the other new extensions like SimpleXML, SOAP, PDO , etc. to take
advantage of it when exposing data types.This is what I talk about when I say a common Date object in php.
Derick exported the headers on my demand, this is a good first step.I think this should be seriously considered. I'll be happy to
work with you on this if it makes sense to you and others.
I think that this functionality is best to be developed in
parallel to 5.1. As it would be new unrelated functionality, I
think we could introduce it in 5.1.x after 5.1.0 is out and once
everyone feels comfortable with it. I don't think rushing it into
5.1.0 is a good idea especially if my feedback is considered.If the 5.1.x that will have that is not too close from 5.1 (new job
on 8th august...), I have some really good additions, they are
nearly all unit tested, remains some doc ;). I will commit part of
it in the next weeks (minus TZ as it conflicts with Derick's one...)As I said in another post, I do not have either the time or the
motivations to port everything to ext/date. I partially disagree on
some design choices and pecl/date has been totally ignored by
Derick, that does not help :).Having the current code in 5.1.0 for some weeks will help to fix it
and find possible issues, errors, or needs requested by extension
developers. Then we can safely add this new API as experimental for
the 1st release. Once everyone agrees (or no one complained), we
will freeze it.Regards,
--Pierre
Since the underlying way of passing internal data would be an object,
the functions you propose may as well be object methods. Aside from that
the API looks good.
Ilia
Hi,
Are there any plans for an interval/date span/duration type of object?
It would be especially nice to have something like postgresql interval
and XML Schema duration datatype where there are additional fields for
months and years, not just the plain old unsurprising
days,hours,minutes,seconds format. (actually, as this year demonstrates,
even minutes aren't all equal)
Otherwise great work. Looking forward to a well rounded and intuitive
date support in PHP.
Ants Aasma