Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:98383 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 78654 invoked from network); 2 Mar 2017 16:33:47 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 2 Mar 2017 16:33:47 -0000 Authentication-Results: pb1.pair.com smtp.mail=rasmus@mindplay.dk; spf=permerror; sender-id=unknown Authentication-Results: pb1.pair.com header.from=rasmus@mindplay.dk; sender-id=unknown Received-SPF: error (pb1.pair.com: domain mindplay.dk from 209.85.220.177 cause and error) X-PHP-List-Original-Sender: rasmus@mindplay.dk X-Host-Fingerprint: 209.85.220.177 mail-qk0-f177.google.com Received: from [209.85.220.177] ([209.85.220.177:33175] helo=mail-qk0-f177.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 05/37-20342-A6948B85 for ; Thu, 02 Mar 2017 11:33:47 -0500 Received: by mail-qk0-f177.google.com with SMTP id n127so132196665qkf.0 for ; Thu, 02 Mar 2017 08:33:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mindplay-dk.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=GVy3biMugxoaKc3MZ0+I9AfpwtuQa3qo/Kvjg5vbfQE=; b=xmwXv38q12pPkRbuXvRWf4HRxJ4w10CRw0gr5AV+iLy3VvV6pGC2nAgEBkMztklEXT fFfqQN4bSk3XJf08EUX8X6dMZ9qHTMlaDqgTmwbxpDAHdNa//eH5rza4BWo+qbqaSxek W8JOfAkScNmL+r6OqqA/aIpz7xH08t0WsaBlrjUwutQY9rHdIZT/XlP/I8DJR15vVeoi SUhBPqZKsUcB6gkAqdKKqjSZhtRYWkhXMRLPqXfGrmNp/Xl3QK2fcSry0rrpvqlMhviy 4M7VMnetzaQUcoTzcQdHECqHoWSRBxO1FnA/ayxK/UbpjPQkOpiDJ7uXEAJoDRVHDA6a il9w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=GVy3biMugxoaKc3MZ0+I9AfpwtuQa3qo/Kvjg5vbfQE=; b=Ow7j4fQ130KzW4bJEz0dlDRL+r1qQL52hYkP2OAhiuX0pkMQ8+l1HmOft06X54HeBv Oqkrkj0nj+jXEkjvlSr/sv9+ux+VenHD4IUpfH9UKAiUDCuv2M4PFLvQzQWrbmfzqYH6 dFKTg7QP/U6EpxYDzEiUFvuuZYgNzh45ogY3oKEhDM8SRfW59rO9+vwmm2L+mCEN7RVh zRYCQZDOo1/TIfJ6k7tL6z6VSKuM/FM/bPtP6ZU3hELdNKBBBUOsTODBBTr6lOaN6KMH W+eOOzrKgWjk7RouRDx+naj7Gg72zVIICJ1DhhOzhDmxia4gUkQ3VNv0AhLpeUTrrjyY yqQg== X-Gm-Message-State: AMke39l3BS3UNEuSiuLM2u9Ta4qjxXvXmVf/lAqRPpPEZcvUk+RqqetVJtOPhi51paP5bbnrhNfO2ghvTdn7YA== X-Received: by 10.55.204.11 with SMTP id r11mr18489951qki.169.1488472423899; Thu, 02 Mar 2017 08:33:43 -0800 (PST) MIME-Version: 1.0 Received: by 10.237.37.60 with HTTP; Thu, 2 Mar 2017 08:33:43 -0800 (PST) In-Reply-To: References: Date: Thu, 2 Mar 2017 17:33:43 +0100 Message-ID: To: Crocodile Cc: Andreas Heigl , PHP Internals Content-Type: multipart/alternative; boundary=001a1149a43e15cb3b0549c1fe28 Subject: Re: [PHP-DEV] New constants in DateTime From: rasmus@mindplay.dk (Rasmus Schultz) --001a1149a43e15cb3b0549c1fe28 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable FWIW, these constants are not universal. In Postgres (and MySQL since 5.7) the date+time types have optional sub-second precision - which the "Y-m-d H:i:s" pattern will fail to parse. Another common case in Postgres is date+time with timezone, e.g. used for scheduling/calendar applications etc. - yet another pattern. Not an argument against having these constants, at all, but they've already been defined everywhere in userland where needed, so, as others have said, I'm not really sure what adding them to the core will accomplish. We'll likely still need other similar constants for other formats. > It's surely easy to implement them in userland but that would require > either global constants or a class in userland specifically for that > purpose I think it's more common to declare them in the class that needs them - for such a small dependency as a date/time pattern, I would honestly prefer to have them plainly visible, declared in the relevant class, next to other related constants, such as date/time regex for input-validation, etc. Likewise, I'd prefer to have minute/hour/day constants defined where needed - I find that const DAY =3D 24*60*60 is more easily parsed and understood than a predefined const DAY =3D 86400. That's all based on personal preference - but namely because it is largely a matter of convenience/preference/opinion, and since it's no burden to declare these at all, perhaps these are good reasons to leave it in userland. On Thu, Mar 2, 2017 at 4:46 PM, Crocodile wrote: > While I agree with everything you're saying, I also think it could still = be > worth it to have those constants in core for the following reasons: > > 1. MINUTE, HOUR and DAY are particularly often used, 99.999% of the time = in > a context where it does not matter if a minute has 60 seconds or not, or = if > a day has 24h or not. Particularly often used to specify cache lifetime, > for example. > 2. It's surely easy to implement them in userland but that would require > either global constants or a class in userland specifically for that > purpose. Both ways are easy, but these constants I see in virtually any > project, so for me it would be handy to have them in DateTime. > > But of course, I don't see it as a must-have, just as nice-to-have. > > Cheers, > Victor > > On Thu, Mar 2, 2017 at 4:03 PM Andreas Heigl wrote: > > > Hi Victor. > > > > > > Am 02.03.17 um 15:48 schrieb Crocodile: > > > Hello internals, > > > > > > A similar question should have been asked already but I haven't found > > > anything so far when googling: I think DateTime class should have the > > > following constants in addition to those already existing: > > > > > > const SQL =3D "Y-m-d H:i:s"; > > > const SQL_DATE =3D "Y-m-d"; > > > const SQL_TIME =3D "H:i:s"; > > > const SECOND =3D 1; > > > const MINUTE =3D 60; > > Not every minute has 60 seconds. > > > const HOUR =3D 3600; > > See above! > > > const DAY =3D 86400; > > Not every day has 86400 seconds. For one see the comment on MINUTE and > > also there are days that have more or less than 24 hours (DST) > > > > Therefore I wouldn't want to see those constants (that are also very > > easy to put up in userland - even though they aren't correct) in the > > PHP-Core. > > > > And as the SQL-Constants are also easily to implement in userland I'm > > not sure it makes to add them to the core=E2=80=A6 > > > > But that's just my 0.02=E2=82=AC > > > > Cheers > > > > Andreas > > > > > > -- > > ,,, > > (o o) > > +---------------------------------------------------------ooO-(_)-Ooo-+ > > | Andreas Heigl | > > | mailto:andreas@heigl.org N 50=C2=B022'59.5" E 08=C2= =B023'58" | > > | http://andreas.heigl.org http://hei.gl/wiFKy7 | > > +---------------------------------------------------------------------+ > > | http://hei.gl/root-ca | > > +---------------------------------------------------------------------+ > > > > -- > Best regards, > Victor Bolshov > --001a1149a43e15cb3b0549c1fe28--