Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:116037 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 93221 invoked from network); 13 Sep 2021 11:47:49 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 13 Sep 2021 11:47:49 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 6C605180511 for ; Mon, 13 Sep 2021 05:26:47 -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.0 required=5.0 tests=BAYES_00,BODY_8BITS, HTML_MESSAGE,KHOP_HELO_FCRDNS,SPF_HELO_NONE,SPF_NONE,UNPARSEABLE_RELAY autolearn=no autolearn_force=no version=3.4.2 X-Spam-ASN: AS16276 94.23.0.0/16 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 ; Mon, 13 Sep 2021 05:26:46 -0700 (PDT) Received: from authenticated-user (PRIMARY_HOSTNAME [PUBLIC_IP]) by processus.org (Postfix) with ESMTPA id B7A425101324; Mon, 13 Sep 2021 12:26:40 +0000 (UTC) To: Andreas Heigl , Hans Henrik Bergan , PHP internals References: <9ECA71F4-F57A-4184-9713-0EF8B7131F97@php.net> <9422892e-9d6a-edf7-47e9-ce6cf91b65bc@heigl.org> Message-ID: Date: Mon, 13 Sep 2021 14:26:39 +0200 MIME-Version: 1.0 In-Reply-To: <9422892e-9d6a-edf7-47e9-ce6cf91b65bc@heigl.org> Content-Type: multipart/alternative; boundary="------------93962560CFCD89475544039F" 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] DateTimeZone silently falls back to UTC when providing seconds From: pierre-php@processus.org (Pierre) --------------93962560CFCD89475544039F Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Le 13/09/2021 à 14:06, Andreas Heigl a écrit : > Hey > > What use-case does it serve to allow offsets that are not reflected in > the TZDB? Yes there are use cases: * Your TZDB is obsolete, your hardware and OS is obsolete, but the prod is still running (it happens more than you think). * You don't care about the TZ name and just use offsets (it happens also, happened to me not so long ago I needed to convert dates with arbitrary offset from some storage). * You fetch dates from a storage which doesn't care about time zone names (hello any SQL database), for example pgsql doesn't store offsets only UTC time, but it accepts arbitrary offsets as input, regarding output dates converted to the explicitly asked time zone or client connection time zone (so actually you this is not a valid use case, but I wanted to highlight that pgsql accepts any arbitrary offset). * You fetch broken dates with broken timezone from a broken storage, but you have to deal with those dates one way or another. There as many good reasons for accepting arbitrary offset that there are offsets on each, so basically that 24*60 good reasons. That's my opinion, as being confronted with dates problems quite often. Just for fun, some pgsql random select: db=# select timestamp with time zone '2021-09-13 14:24:00+03:15' at time zone 'utc';       timezone ---------------------  2021-09-13 11:09:00 Regards, -- Pierre --------------93962560CFCD89475544039F--