Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:124158 X-Original-To: internals@lists.php.net Delivered-To: internals@lists.php.net Received: from php-smtp4.php.net (php-smtp4.php.net [45.112.84.5]) by qa.php.net (Postfix) with ESMTPS id E5B201A009C for ; Mon, 1 Jul 2024 18:46:08 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=php.net; s=mail; t=1719859649; bh=oWNOo1X7BD5l+ZcZ6MGozIwAUn4bFGrYdq1ceImgvi0=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=GJdFmXNBWv3h+bOXmSyywwoYCJkhdYt/G8o6/8uq+j4SxEm+9W9Mk5P3+4nWLmvmY lvjfMrJexTMThBxQGjgykS+83iylELXqgT0e/ktKhf2HVQ5EmVrozothg3YSWXzlP4 jEYBpIHvQ4kbWYXK8fz9a2faTYxRdG/v8j64MpWY0WcCs36aPxxpieEL8AKJCBTjQD OW01v0mGDJwIaUpx7/8r+4GeiOkZLcJYF76rLx934nFLzIXK5KY4mn1dYrFM5OLNYq GbgySykrljHKlxmx2CP4dQFStNb4xkaTtkKHlxVt0UfjlQtREXLtMR5rtbJOZRhXzl c0hT9s8oAMYWQ== Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 799B51807FC for ; Mon, 1 Jul 2024 18:47:26 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 4.0.0 (2022-12-13) on php-smtp4.php.net X-Spam-Level: X-Spam-Status: No, score=0.6 required=5.0 tests=BAYES_50,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,DMARC_PASS,FREEMAIL_FROM, HTML_MESSAGE,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE, SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=4.0.0 X-Spam-Virus: Error (Cannot connect to unix socket '/var/run/clamav/clamd.ctl': connect: Connection refused) X-Envelope-From: Received: from mail-vk1-f176.google.com (mail-vk1-f176.google.com [209.85.221.176]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Mon, 1 Jul 2024 18:47:23 +0000 (UTC) Received: by mail-vk1-f176.google.com with SMTP id 71dfb90a1353d-4ef2006dcdbso1105617e0c.3 for ; Mon, 01 Jul 2024 11:46:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1719859562; x=1720464362; darn=lists.php.net; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=XxQf59izQzMHBrqgxO6tTRdomwdbHaGmGGx5CDh70Ik=; b=HTdHSFcveRD0ocdmDUHvsqFnMwWwYRMXqznm+zb5Y7c/eBKxhCQDuLd3/EedE4/LFo vu6C1zrGF0P6fcMXNwzFbNg471r2kvgAcoYqdSLQvhFIIfxXKCFmCYagCLR1KmnKUrZ4 UKBWeW69HbLiBO6l2EMlxv1qnAW2CCpIMx01hZygLA1LnxruvSx0/LiatMAhOa1ie0Ec Kqj62RIov0w0KuKlJIH57eSk9duf2b2wbtAyX4/P05+98+ACNy2959Um8z7NJlQm6zIH IT7PXPUTzXqpC5adpGjsrylx0K04vnxoo26eHPXNVG1mJ6NV6tbVuM0hCbDOYd0N59NW mAZQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1719859562; x=1720464362; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=XxQf59izQzMHBrqgxO6tTRdomwdbHaGmGGx5CDh70Ik=; b=RAJ4MxSiY2LgTf7PzQeVM9y5+uc6LwLBQcWAK6+EZgYCtX+xvoJHmzqxX/uLcTC1yt aS5xBCfzucTfWupi/dBd2tJb5UL5pbf4OFfidb+qveLOAEr/epDO8oT/ogTry8Eo0AZO nmyjzLSLwVLyBcewxskH+2jKlIk8tk7VyxW5W8JouTmzDHUxmC5s7ZksJlVmaX6UUpMt nv/ChvL6QQA102SOK5ix1kxDY5drs7MBr+yIIBQkftezVy4WMol6Sg8X4mct08onr5+9 HxYiJIAgBE/6Ixrqoe6kyAqufMkV6Qc2iAKIbw9mVqLzQjXK4bGdwGy/dNcXmySDD2Wy aKOA== X-Gm-Message-State: AOJu0YxKnYdCbM1B8seLPZto3pIOetyIwhIdOL0UwXRuu7sIyQ20HKyu zOWDF5APOaYIdWfBDBxTfI3aRh7o3kTbjxiG0Ruh9jzx3nJywnpJav2KDxk5j/U1+hTSC/XkcV5 wA07tW7QdNdCUzYDIjijkkm22qky3dw== X-Google-Smtp-Source: AGHT+IHCuRyQCcYMlQpjIzcPqipuIqDCHzhLYYV+b5eD8uDltiehucMMPrp8fn2y+0gLQ42wDDJaY50f4VndwgJqEt0= X-Received: by 2002:a05:6122:4893:b0:4ed:12b:ec99 with SMTP id 71dfb90a1353d-4f2a563e1a8mr8118225e0c.3.1719859562083; Mon, 01 Jul 2024 11:46:02 -0700 (PDT) Precedence: bulk list-help: list-post: List-Id: internals.lists.php.net MIME-Version: 1.0 References: In-Reply-To: Date: Mon, 1 Jul 2024 12:45:51 -0600 Message-ID: Subject: Re: [PHP-DEV] Re: [Discussion] Add date_test_set_now() function To: Larry Garfield Cc: php internals Content-Type: multipart/alternative; boundary="00000000000042ff7b061c34027d" From: lnearwaju@gmail.com (Lanre) --00000000000042ff7b061c34027d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Jul 1, 2024 at 12:42=E2=80=AFPM Lanre wrote: > Larry, > > Your absolutes and comments like "Relying on global mutable state is a > bug" are incredibly frustrating. Are the authors of Carbon and Chronos, t= he > two biggest userland time libraries, somehow wrong because they aren=E2= =80=99t you? > Do you think they didn=E2=80=99t put any thought into their decisions and= just > relied on global mutable state for no reason? > > There are multiple internal functions that rely on global state, such as > date_default_timezone_set(), date_default_timezone_get(), mktime(), > gmmktime(), setlocale(), localeconv(), set_error_handler(), > restore_error_handler(), set_exception_handler(), > restore_exception_handler(), session_start(), session_destroy(), > session_set_save_handler(), session_id(), srand(), rand(), mt_srand(), > mt_rand(), stream_context_create(), stream_context_set_option(), > stream_context_set_params(), ob_start(), ob_get_contents(), ob_get_clean(= ), > ob_flush(), ob_end_flush(), import_request_variables(), ini_set(), > ini_get(), ini_restore(), timezone_identifiers_list(), and timezone_name_= from_abbr(), > are those also to be considered bugs? > > Isn=E2=80=99t PSR a recommendation, not a mandate? How can it be "the cor= rect > answer"? (we get it, you're a member of PHP-FIG) > > You don=E2=80=99t make any effort to help or provide constructive critici= sm; you > just love to (incorrectly) tell everyone what they're doing wrong and how > they should be doing it, without adding anything constructive to the > conversation. > > Cheers, > > Lanre > > On Mon, Jul 1, 2024 at 12:13=E2=80=AFPM Larry Garfield > wrote: > >> On Mon, Jul 1, 2024, at 3:56 PM, Go Kudo wrote: >> >> > I apologize, the main point of my explanation was off. >> > >> > To put it simply, I'm suggesting that it might be good to implement >> > convenient and commonly used features from Carbon at the ext-date leve= l. >> > >> > I'm proposing the date_test_set_now() function for the following >> reasons: >> > >> > User-land libraries like Carbon / Chronos have a setTestNow method, >> > indicating a potential demand for this feature. >> > It's impossible to determine whether a value is relative or absolute >> > time from either user-land or Extension. >> > While this is convenient for maintaining legacy systems, that's not th= e >> > essence of this proposal. >> > >> > As you pointed out, this is an issue that should ideally be solved in >> > user-land. I deeply understand that. >> > >> > However, in reality, PHP's time-related processing is diverse, and to >> > comprehensively handle all of these, it seems necessary to address thi= s >> > at the ext-date level. >> > >> > https://www.php.net/manual/en/ref.datetime.php >> > >> > For example, you might want to use the date() function to display the >> > current time on a whim. However, doing this ruins everything. >> > >> > Even if other parts of your code use Carbon or comply with PSR-20, >> > using the date() function is problematic because the current time it >> > references cannot be modified. >> > >> > `date_test_now(\DateInterval $shiftInterval)` can solve this problem. >> > >> > Of course, there might be various side effects. However, seeing >> > `Carbon::setTestNow()` being used in various places, I think this >> > feature might be necessary. >> > >> > I would appreciate your thoughts on this. >> > >> > Best Regards, >> > Go Kudo >> >> They are unchanged. >> >> > For example, you might want to use the date() function to display the >> > current time on a whim. >> >> So don't do that. Relying on global mutable state is a bug. That older >> parts of the stdlib made that mistake doesn't mean we should continue it= . >> (See also the Random extension, which also works to avoid global mutable >> state.) >> >> > Of course, there might be various side effects. >> >> Exactly. This is not something to just brush aside with a comment. >> >> The way Carbon does it is wrong, for the same reason: It just sets a >> global state. The correct answer is to use PSR-20 and inject a fixed-ti= me >> instance of the Clock. >> >> --Larry Garfield >> > My bad for the top post, still getting used to it. Also i think this RFC is a great idea and will be one less reason to use a third party userland library to handle time. Cheers, Lanre --00000000000042ff7b061c34027d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Mon, Jul 1, 2024 at 12:42=E2=80=AF= PM Lanre <lnearwaju@gmail.com= > wrote:

Larry,

Your absolutes and comments like "Relying= on global mutable state is a bug" are incredibly frustrating. Are the= authors of Carbon and Chronos, the two biggest userland time libraries, so= mehow wrong because they aren=E2=80=99t you? Do you think they didn=E2=80= =99t put any thought into their decisions and just relied on global mutable= state for no reason?

There are multiple internal functions that rely= on global state, such as date_default_timezone_set(), d= ate_default_timezone_get(), mktime(), gmmktime()<= /code>, setlocale(), localeconv(), set_erro= r_handler(), restore_error_handler(), set_excepti= on_handler(), restore_exception_handler(), sessio= n_start(), session_destroy(), session_set_save_ha= ndler(), session_id(), srand(), rand= (), mt_srand(), mt_rand(), stream_co= ntext_create(), stream_context_set_option(), stre= am_context_set_params(), ob_start(), ob_get_conte= nts(), ob_get_clean(), ob_flush(), o= b_end_flush(), import_request_variables(), ini_se= t(), ini_get(), ini_restore(), timez= one_identifiers_list(), and timezone_name_from_abbr(), are tho= se also to be considered bugs?

Isn=E2=80=99t PSR a recommendat= ion, not a mandate? How can it be "the correct answer"? (we get i= t, you're a member of PHP-FIG)

You don=E2=80=99t make any effort = to help or provide constructive criticism; you just love to (incorrectly) t= ell everyone what they're doing wrong and how they should be doing it, = without adding anything constructive to the conversation.

Cheers,

=

Lanre


On Mon, Jul 1, 2024 at 12:13=E2=80=AFPM Larry Garfield <larry@garfieldtech.= com> wrote:
On Mon, Jul 1, 2024, at 3:56 PM, Go Kudo wrote:

> I apologize, the main point of my explanation was off.
>
> To put it simply, I'm suggesting that it might be good to implemen= t
> convenient and commonly used features from Carbon at the ext-date leve= l.
>
> I'm proposing the date_test_set_now() function for the following r= easons:
>
> User-land libraries like Carbon / Chronos have a setTestNow method, > indicating a potential demand for this feature.
> It's impossible to determine whether a value is relative or absolu= te
> time from either user-land or Extension.
> While this is convenient for maintaining legacy systems, that's no= t the
> essence of this proposal.
>
> As you pointed out, this is an issue that should ideally be solved in =
> user-land. I deeply understand that.
>
> However, in reality, PHP's time-related processing is diverse, and= to
> comprehensively handle all of these, it seems necessary to address thi= s
> at the ext-date level.
>
> https://www.php.net/manual/en/ref.datetime.php
>
> For example, you might want to use the date() function to display the =
> current time on a whim. However, doing this ruins everything.
>
> Even if other parts of your code use Carbon or comply with PSR-20, > using the date() function is problematic because the current time it <= br> > references cannot be modified.
>
> `date_test_now(\DateInterval $shiftInterval)` can solve this problem.<= br> >
> Of course, there might be various side effects. However, seeing
> `Carbon::setTestNow()` being used in various places, I think this
> feature might be necessary.
>
> I would appreciate your thoughts on this.
>
> Best Regards,
> Go Kudo

They are unchanged.=C2=A0

> For example, you might want to use the date() function to display the =
> current time on a whim.

So don't do that.=C2=A0 Relying on global mutable state is a bug.=C2=A0= That older parts of the stdlib made that mistake doesn't mean we shoul= d continue it.=C2=A0 (See also the Random extension, which also works to av= oid global mutable state.)

> Of course, there might be various side effects.

Exactly.=C2=A0 This is not something to just brush aside with a comment.=C2= =A0

The way Carbon does it is wrong, for the same reason: It just sets a global= state.=C2=A0 The correct answer is to use PSR-20 and inject a fixed-time i= nstance of the Clock.

--Larry Garfield



Lanre
--00000000000042ff7b061c34027d--