Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:113337 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 14250 invoked from network); 3 Mar 2021 11:03:15 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 3 Mar 2021 11:03:15 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 107741804B4 for ; Wed, 3 Mar 2021 02:53:44 -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=-1.5 required=5.0 tests=BAYES_00,KHOP_HELO_FCRDNS, SPF_HELO_NONE,SPF_NONE,UNPARSEABLE_RELAY autolearn=no autolearn_force=no version=3.4.2 X-Spam-Virus: No X-Envelope-From: Received: from processus.org (ns366368.ip-94-23-14.eu [94.23.14.201]) (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 02:53:43 -0800 (PST) Received: from authenticated-user (PRIMARY_HOSTNAME [PUBLIC_IP]) by processus.org (Postfix) with ESMTPA id 5E1625101324 for ; Wed, 3 Mar 2021 10:53:41 +0000 (UTC) To: internals@lists.php.net References: Message-ID: <09ef54b2-a6b1-5bf5-8562-f2f436fd4d92@processus.org> Date: Wed, 3 Mar 2021 11:53:40 +0100 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Authentication-Results: processus.org; auth=pass smtp.auth=pierre-php@processus.org smtp.mailfrom=pierre-php@processus.org X-Spamd-Bar: / Subject: Re: [PHP-DEV] Add __toString() to DateInterval From: pierre-php@processus.org (Pierre) Le 03/03/2021 à 11:37, Moritz Friedrich a écrit : > Hi internals, > I’ve been active in the PHP ecosystem as @Radiergummi for quite a while now, but not on internals yet, so: nice to meet you all! > > I would like to propose adding a `__toString()` method to the `DateInterval` class that should return a valid ISO8601 interval (https://en.wikipedia.org/wiki/ISO_8601#Time_intervals). As it stands, the class supports creating instances from such interval strings passed to its constructor, but the reverse isn’t true: The only way to build a string representation of the interval is by querying the `DateInterval::format` method for the individual durations multiple times (see https://stackoverflow.com/questions/33787039/format-dateinterval-as-iso8601#answers for examples). > > Allowing to cast `DateInterval`s to strings would make the most sense in my opinion, and probably doesn’t break BC. Use cases include communicating with other APIs that work with ISO8601, or persistence of periods in databases, for example. > > So instead of the following: > > function formatDateInterval(DateInterval $interval, string $default = '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; > } > > formatDateInterval(new DateInterval('P1DT5H')) === 'P1DT5H' > > I’d like to be able to do this: > > (string)new DateInterval('P1DT5H') === 'P1DT5H' > > Following alternative approaches come to mind: > > 1. Adding a new, specialized method to the class (eg. `DateInterval::toIsoString(): string`): > While being the most BC-safe option, this would be completely different to the rest of the PHP date APIs. > > 2. Adding a new interval format constant to be passed to `DateInterval::format` (eg. `DATE_INTERVAL_ISO8601`): > Most in line with the `DateTime` API, but probably requires special case handling in `format` code. > > From those, having `__toString` seems most desirable to me. > While I’m not proficient with C, I’d really like to see this implemented and would gladly help out where I can. Might someone be able to advise? > > > Sincerely > Moritz / Radiergummi Hello, I don't like implicit __toString() methods, they have to be very carefully documented and it's "magic". Wouldn't it be best to have both the `toIsoString()` and `__toString()` (as a fallback) methods ? Having the constant is a good idea too, it would make it probably more consistent with the DateTime class, I'm not opposed having three variations to do skin the same cat. Regards, Pierre