date/timezone classes

Pierre-Alain Joye

21 years ago

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

Derick Rethans

21 years ago

On Thu, 7 Jul 2005, Pierre-Alain Joye wrote:

> 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

Andi Gutmans

21 years ago

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:

Pierre-Alain Joye

21 years ago

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

Edin Kadribasic

21 years ago

On Friday 08 July 2005 02:17, Pierre-Alain Joye wrote:
[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

Derick Rethans

21 years ago

On Fri, 8 Jul 2005, Edin Kadribasic 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 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

Pierre-Alain Joye

21 years ago

On Fri, 8 Jul 2005 14:31:14 +0200 (CEST)
Derick Rethans <derick@php.net> wrote:

> On Fri, 8 Jul 2005, Edin Kadribasic 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 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).

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

Andi Gutmans

21 years ago

At 02:36 PM 7/8/2005 +0200, Pierre-Alain Joye wrote:

>On Fri, 8 Jul 2005 14:31:14 +0200 (CEST)
>Derick Rethans <derick@php.net> wrote:
>
> > On Fri, 8 Jul 2005, Edin Kadribasic 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 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).
>
>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.

Great. I definitely think you two should work together on this one.

Andi

Marcus Boerger

21 years ago

Hello Derick,

Friday, July 8, 2005, 2:31:14 PM, you wrote:

> On Fri, 8 Jul 2005, Edin Kadribasic 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

Andrei Zmievski

21 years ago

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

On Jul 8, 2005, at 1:06 PM, Marcus Boerger wrote:

Marcus Boerger

21 years ago

Hello Andrei,

++++++++1

Monday, July 11, 2005, 7:16:45 PM, you wrote:

Pierre-Alain Joye

21 years ago

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

Derick Rethans

21 years ago

On Mon, 11 Jul 2005, Pierre-Alain Joye 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.

Derick

--
Derick Rethans
http://derickrethans.nl | http://ez.no | http://xdebug.org

Edin Kadribasic

21 years ago

Derick Rethans wrote:

> On Mon, 11 Jul 2005, Pierre-Alain Joye 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

Derick Rethans

21 years ago

On Mon, 11 Jul 2005, Derick Rethans wrote:

> On Mon, 11 Jul 2005, Pierre-Alain Joye 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.

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

Andi Gutmans

21 years ago

Guys,

I definitely think that the path to 5.1 currently has to focus on PDO and
the ZE stabilizing. I plan to release Beta 3 hopefully tomorrow (a bit late
because I'm still waiting for some PDO fixes Wez wants to make). Commiting
a new Date extension at this point is definitely high risk. Derick probably
wouldn't agree if it were someone else :)
I personally would prefer this work to be done in PECL and roll them into
HEAD once they have stabilized. As it's new functionality it could also be
in a mini release (5.1.1, 5.1.2) which will surely follow quickly after
5.1.0. I don't see why we need to be in such a rush... There is no reason
this won't get out to the masses. As it is, it was questionable wether my
call to allow changing the core Date functions at such a late time in the
game was a good call by me.

Andi

At 12:27 AM 7/12/2005 +0200, Derick Rethans wrote:

George Schlossnagle

21 years ago

On Jul 7, 2005, at 7:56 PM, Andi Gutmans wrote:

>
> 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.

+1

Andi Gutmans

21 years ago

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:

Derick Rethans

21 years ago

On Thu, 7 Jul 2005, Andi Gutmans wrote:

> 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).

Objects are not harder to implement, I found it actually more straight
forward. Besides that, making it an object allows other people to extend
it, something that Pierre wants for his pecl/date.

> 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);

Those are not equivalent.

> $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.

? The way how they expose datatypes doesn't really differ. It's just
that *currently* I've no plans to add fancy methodnames. All other
functions on standard datatypes work with functions. This falls IMO in
the same category as not wanting a full blown String class in the core
of PHP.

Derick

Pierre-Alain Joye

21 years ago

On Fri, 8 Jul 2005 09:16:29 +0200 (CEST)
derick@php.net (Derick Rethans) wrote:

> Objects are not harder to implement, I found it actually more
> straight forward. Besides that, making it an object allows other
> people to extend it, something that Pierre wants for his pecl/
> date.

I do not want to extend a basic date object. This adds overheads for
nothing. pecl/date was originally designed to be integrated in php,
see:
http://marc.theaimsgroup.com/?l=php-dev&m=104540995515576&w=2

Integrate it in ext/date, keeping full BC with existing functions as
they do not change. When the implementations reach a stable state,
we could have been able to use it inside the current functions and
move them to ext/date.

By the way, an object with basic method/properties and more
"advanced" methods/ properties will not consume more memory, will
not add overhead to people who does not want to use an object.

> ? The way how they expose datatypes doesn't really differ. It's
> just that *currently* I've no plans to add fancy methodnames. All
> other functions on standard datatypes work with functions. This
> falls IMO in the same category as not wanting a full blown String
> class in the core of PHP.

Even if I agree on you about a String class, you miss the point. A
12k buffer upper cased with current functions ends with 2x 12k
buffers.

About a date/time object, these values have much more properties.
It is slighty more difficult to deal with them (non linear,
exceptions, etc.). People needs to work with ranges, arythmetics.
They also need some simple (and fast) function to get informations
other than the current properties.

Another additions are iterators, filtered iterators are a killing
feature for people having to create complex calendar applications.
a complex calendar applications is something else that the current
month calendar displayed on every single blog out there.


But words are sometimes useless, I will put my thoughts in pecl/
date. This is a perfect place to make experiments on an usefull
APIs and get feedbacks. Once we (not only you and me but everyone
having some clue) agree on the features and the specifications, we
can then put in ext/date.

Regards,

--Pierre

Marcus Boerger

21 years ago

Hello Pierre-Alain,

since we now have ext/date shouldn't we rename pecl/date to
something different for easier integration? And i also do not
know if we aren't running into problems later if two extensions
have the same name.

marcus

Friday, July 8, 2005, 12:44:45 PM, you wrote:

> On Fri, 8 Jul 2005 09:16:29 +0200 (CEST)
> derick@php.net (Derick Rethans) wrote:

>> Objects are not harder to implement, I found it actually more
>> straight forward. Besides that, making it an object allows other
>> people to extend it, something that Pierre wants for his pecl/
>> date.

> I do not want to extend a basic date object. This adds overheads for
> nothing. pecl/date was originally designed to be integrated in php,
> see:
> http://marc.theaimsgroup.com/?l=php-dev&m=104540995515576&w=2

> Integrate it in ext/date, keeping full BC with existing functions as
> they do not change. When the implementations reach a stable state,
> we could have been able to use it inside the current functions and
> move them to ext/date.

> By the way, an object with basic method/properties and more
> "advanced" methods/ properties will not consume more memory, will
> not add overhead to people who does not want to use an object.

>> ? The way how they expose datatypes doesn't really differ. It's
>> just that *currently* I've no plans to add fancy methodnames. All
>> other functions on standard datatypes work with functions. This
>> falls IMO in the same category as not wanting a full blown String
>> class in the core of PHP.

> Even if I agree on you about a String class, you miss the point. A
> 12k buffer upper cased with current functions ends with 2x 12k
> buffers.

> About a date/time object, these values have much more properties.
> It is slighty more difficult to deal with them (non linear,
> exceptions, etc.). People needs to work with ranges, arythmetics.
> They also need some simple (and fast) function to get informations
> other than the current properties.

> Another additions are iterators, filtered iterators are a killing
> feature for people having to create complex calendar applications.
> a complex calendar applications is something else that the current
> month calendar displayed on every single blog out there.

> But words are sometimes useless, I will put my thoughts in pecl/
> date. This is a perfect place to make experiments on an usefull
> APIs and get feedbacks. Once we (not only you and me but everyone
> having some clue) agree on the features and the specifications, we
> can then put in ext/date.

> Regards,

> --Pierre

--
Best regards,
Marcus                            mailto:mail@marcus-boerger.de

Ilia A.

21 years ago

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

Ants Aasma

21 years ago

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