Re: Fix for bug #63437
| From: | Derick Rethans | Date: | Sat, 09 Mar 2013 23:49:15 +0000 |
| Subject: | Re: Fix for bug #63437 | ||
| References: | 1 2 3 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-66572@lists.php.net to get a copy of this message | ||
On Sat, 9 Mar 2013, Gustavo Lopes wrote:
> On Sat, 09 Mar 2013 21:36:41 +0100, Derick Rethans <derick@php.net> wrote:
>
> > On Tue, 5 Mar 2013, Anatol Belski wrote:
> >
> > > I've reworked the patch from
> > >
> > > http://nebm.ist.utl.pt/~glopes/misc/date_period_interval_ser.diff
> > > (mentioned by tony2001) for bug #63437, that seems to fix the
> > > issue. That patch was ported back to 5.3 and adapted to the
> > > current 5.4+. Both variants are posted to the ticket.
> >
> > Serializing this as a base64 encoded variant of some binary data is
> > not a good thing. If you want to serialize, it needs to output the
> > same thigns that allow users to create the period or interval.
>
> I would agree in principle, but, as I explained before, there is a
> problem. The DatePeriod class has 64-bit integers in its internal
> structure. The PHP integer type cannot (in general) represent that
> data. So the general method of getting the object data via
> get_properties and serializing (and then using __set_state to convert
> the array back) does not work unless you represent those 64-bit
> integers with some non-integer type and do the conversions.
Then store them as strings or another format that makes it possible to
get a 64bit timestamp back. Of course, I don't think it makes too much
sense to serialize a Period as it's more of a transient iterator
wrapper. For an interval, you'd want to serialise the original input
vectors as well... not an easy task (unless you store the original).
cheers,
Derick