Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:113345 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 37951 invoked from network); 3 Mar 2021 14:08:34 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 3 Mar 2021 14:08:34 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 38FEE1804D3 for ; Wed, 3 Mar 2021 05:59:02 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on php-smtp4.php.net X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,RCVD_IN_DNSWL_LOW,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL, SPF_HELO_PASS,SPF_NONE autolearn=no autolearn_force=no version=3.4.2 X-Spam-Virus: No X-Envelope-From: Received: from wout2-smtp.messagingengine.com (wout2-smtp.messagingengine.com [64.147.123.25]) (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 ; Wed, 3 Mar 2021 05:59:01 -0800 (PST) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.west.internal (Postfix) with ESMTP id 704D81810 for ; Wed, 3 Mar 2021 08:59:00 -0500 (EST) Received: from imap8 ([10.202.2.58]) by compute4.internal (MEProxy); Wed, 03 Mar 2021 08:59:00 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; bh=dBxDDuTKssosYMWMoWEEvoqoPlPIMukG/iOXmpQgd YY=; b=gzIoi7WI5I7E1ZZlGM9xl1+zKFX4XIFNwHe2cgtDTG73sazZRQPCZyrRe MEyOkzuzTKkdhHQWz65rKxFyQM+O4/EfD+oel+Me0ZkZM51ahMHe9fIn97zpgQ75 6DcGanKCzpifSzWBcs/FsEJmfw2Q9mgg2B6T5QEBfArEZ09i2LxhbIiHSFsdGVWe wa+wG3K9Vkr/hi4ABWghFGUu13FB6EWD1vWP9E0/XquiPgFjFttAXhA858z6R6tC SFRS5D6QrMKJb8S5ZuvWAUA6zAeos/hw6yIqanm4m0x728/l9DH0+ZUn+rza3xRa l5W0EiAigao2R1kRWhZTvfnS7aeZA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledruddtvddgheelucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvffutgfgsehtqhertderreejnecuhfhrohhmpedfnfgr rhhrhicuifgrrhhfihgvlhgufdcuoehlrghrrhihsehgrghrfhhivghlughtvggthhdrtg homheqnecuggftrfgrthhtvghrnhepveejgedvffehteefveefhfffheegtdelieelffet keevhfeuieegvdekteekuefgnecuffhomhgrihhnpeifihhkihhpvgguihgrrdhorhhgpd hsthgrtghkohhvvghrfhhlohifrdgtohhmnecuvehluhhsthgvrhfuihiivgeptdenucfr rghrrghmpehmrghilhhfrhhomheplhgrrhhrhiesghgrrhhfihgvlhguthgvtghhrdgtoh hm X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id CA0183A0244; Wed, 3 Mar 2021 08:58:59 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.5.0-alpha0-206-g078a48fda5-fm-20210226.001-g078a48fd Mime-Version: 1.0 Message-ID: In-Reply-To: References: Date: Wed, 03 Mar 2021 07:58:39 -0600 To: "php internals" Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [PHP-DEV] Add __toString() to DateInterval From: larry@garfieldtech.com ("Larry Garfield") On Wed, Mar 3, 2021, at 4:37 AM, Moritz Friedrich wrote: > Hi internals, > I=E2=80=99ve been active in the PHP ecosystem as @Radiergummi for quit= e a while=20 > now, but not on internals yet, so: nice to meet you all! >=20 > I would like to propose adding a `__toString()` method to the=20 > `DateInterval` class that should return a valid ISO8601 interval=20 > (https://en.wikipedia.org/wiki/ISO_8601#Time_intervals). As it stands,= =20 > the class supports creating instances from such interval strings passe= d=20 > to its constructor, but the reverse isn=E2=80=99t true: The only way t= o build a=20 > string representation of the interval is by querying the=20 > `DateInterval::format` method for the individual durations multiple=20= > times (see=20 > https://stackoverflow.com/questions/33787039/format-dateinterval-as-is= o8601#answers for examples). >=20 > Allowing to cast `DateInterval`s to strings would make the most sense=20= > in my opinion, and probably doesn=E2=80=99t break BC. Use cases includ= e=20 > communicating with other APIs that work with ISO8601, or persistence o= f=20 > periods in databases, for example.=20 >=20 > So instead of the following: >=20 > function formatDateInterval(DateInterval $interval, string $defaul= t=20 > =3D 'PT0S'): string { > return rtrim(str_replace( > ['M0S', 'H0M', 'DT0H', 'M0D', 'P0Y', 'Y0M', 'P0M'], > ['M', 'H', 'DT', 'M', 'P', 'Y', 'P'], > $interval->format('P%yY%mM%dDT%hH%iM%sS') > ), 'PT') ?: $default; > } > =20 > formatDateInterval(new DateInterval('P1DT5H')) =3D=3D=3D 'P1DT5H' >=20 > I=E2=80=99d like to be able to do this: >=20 > (string)new DateInterval('P1DT5H') =3D=3D=3D 'P1DT5H' >=20 > Following alternative approaches come to mind: >=20 > 1. Adding a new, specialized method to the class (eg.=20 > `DateInterval::toIsoString(): string`): =20 > While being the most BC-safe option, this would be completely=20 > different to the rest of the PHP date APIs. >=20 > 2. Adding a new interval format constant to be passed to=20 > `DateInterval::format` (eg. `DATE_INTERVAL_ISO8601`): =20 > Most in line with the `DateTime` API, but probably requires special= =20 > case handling in `format` code. >=20 > From those, having `__toString` seems most desirable to me. =20 > While I=E2=80=99m not proficient with C, I=E2=80=99d really like to se= e this=20 > implemented and would gladly help out where I can. Might someone be=20= > able to advise? I agree that easier round-tripping of interval data is a good thing. As= for which approach to take, I think we should defer to Derick, or at le= ast see what his input is. :-) I don't have a super strong preference b= etween these 3 options, other than not liking the idea of tossing that o= ff to user space. For better or worse DateTime is a core functionality = and API, so it should be implemented in one place. Beyond that, whateve= r Derick feels is most consistent with the rest of the API is OK by me. Let's not bikeshed this into a larger overhaul of the whole DateTime API= . :-) --Larry Garfield