Re: Add __toString() to DateInterval
> I already showed you that: "next weekday". It can either be +1 days, +2
> days, or +3 days.
…depending on the time of execution, yes. The moment a developer consciously decides to transform
an interval to an ISO string representation, they obviously accept the premise of anchoring the
dynamic expression to the current point in time.
> Maybe, but the DateInterval class does not represent a ISO interval
> specification, it represents a timelib interval definition, which you
> can *also* create from an ISO 8601 interval specification.
Isn’t it the other way around? I’d argue that a DateInterval represents an ISO interval
specification according to its constructor, which accepts ISO interval specifications exclusively,
but is *also* capable of creating an instance from a timelib interval definition using the static
helper method createFromDateString. From a userland perspective it doesn’t matter how
timelib handles this internally, as long as the public API stays consistent.
> Converting to just a simple string is not a serialisation, as it loses
> information. If you care about serialisation, then you need to come up
> with a way how to do that for every interval that a DateInterval can
> represent. PHP's "serialize" can already serialise a DateInterval.
…depending on whether you perceive the start and end dates of an interval as an inherent part of
the interval or external constraints. Just because timelib makes the assumption of the latter
doesn’t mean the rest of the world shares this perspective, as emphasized by the fact of the ISO
specification not doing so.
Again, I’m not attached to __toString(). Having another helper method or a special
formatting constant, as suggested by others in this thread, would likewise be a viable option. I’d
merely prefer to have a built-in way of parsing *and* composing time intervals as per the ISO
specification, making the API consistent and easing communication with non-PHP systems.
Regards,
Moritz
Thread (19 messages)