Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:113573 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 88788 invoked from network); 16 Mar 2021 19:02:36 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 16 Mar 2021 19:02:36 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id AE09F1804DF for ; Tue, 16 Mar 2021 11:56:25 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on php-smtp4.php.net X-Spam-Level: X-Spam-Status: No, score=0.2 required=5.0 tests=BAYES_20,DKIM_INVALID, DKIM_SIGNED,SPF_HELO_PASS,SPF_PASS autolearn=no autolearn_force=no version=3.4.2 X-Spam-Virus: No X-Envelope-From: Received: from mail.hades.9dev.de (mail.hades.9dev.de [88.99.187.36]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Tue, 16 Mar 2021 11:56:24 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by localhost (Mailerdaemon) with ESMTPSA id 2AB875E027; Tue, 16 Mar 2021 19:56:22 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=9dev.de; s=dkim; t=1615920982; h=from:subject:date:message-id:to:cc:mime-version:content-type: content-transfer-encoding:in-reply-to:references; bh=IYd3kLFGqN0gejisUyWoq0Oa3afRrffMsNpTy5emIT4=; b=NTsneUaReXcYEfn1PPfEYgiel4PkP2847R52ObtYJxYC9ULdNh2cEhNSB/UQZNTVCxfteH 3Uc83EYwZnwObtMsWkrdwmJefFAd3FjcOMKhD6wOJozQL87uayPEbvl+a3bI6NGGkj7fEp DJ8mIxBw7NIJoIsbvNxIPmpkqQ99u6/9K/NOtIgp2U/N/S2laOo7SMYiFPkOe556o9fw0W IJ6kLmNOsi/TKuoXmrXFhXBC3TrqOZweO6tJrPj+0QcqZUQeejnMSYSo2Sx1V6tSQpqkdS 6hUgY3+Mg1vvbgIswUEvATOO5MsEakdRU9v1gNC348O7vDVaa9RwKxmuNSTPjA== Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.21\)) In-Reply-To: Date: Tue, 16 Mar 2021 19:56:20 +0100 Cc: internals@lists.php.net Content-Transfer-Encoding: quoted-printable Message-ID: <05166649-DFD5-4B93-8D4C-1E19CE129EFF@9dev.de> References: To: Derick Rethans X-Last-TLS-Session-Version: TLSv1.2 Subject: Re: [PHP-DEV] Add __toString() to DateInterval From: m@9dev.de (Moritz Friedrich) > I already showed you that: "next weekday". It can either be +1 days, = +2=20 > days, or +3 days. =E2=80=A6depending 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=20 > specification, it represents a timelib interval definition, which you=20= > can *also* create from an ISO 8601 interval specification. Isn=E2=80=99t it the other way around? I=E2=80=99d 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`. =46rom = a userland perspective it doesn=E2=80=99t 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=20= > information. If you care about serialisation, then you need to come up=20= > with a way how to do that for every interval that a DateInterval can=20= > represent. PHP's "serialize" can already serialise a DateInterval. =E2=80=A6depending 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=E2=80=99t = mean the rest of the world shares this perspective, as emphasized by the = fact of the ISO specification not doing so. Again, I=E2=80=99m 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=E2=80=99d 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.=20 Regards, Moritz=