From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from firstgate.proxmox.com (firstgate.proxmox.com [212.224.123.68]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by lists.proxmox.com (Postfix) with ESMTPS id A2A8177DB7 for ; Thu, 29 Apr 2021 10:49:26 +0200 (CEST) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id 9531318C37 for ; Thu, 29 Apr 2021 10:49:26 +0200 (CEST) Received: from proxmox-new.maurer-it.com (proxmox-new.maurer-it.com [94.136.29.106]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by firstgate.proxmox.com (Proxmox) with ESMTPS id 1802F18C2C for ; Thu, 29 Apr 2021 10:49:26 +0200 (CEST) Received: from proxmox-new.maurer-it.com (localhost.localdomain [127.0.0.1]) by proxmox-new.maurer-it.com (Proxmox) with ESMTP id D649246489 for ; Thu, 29 Apr 2021 10:49:25 +0200 (CEST) Date: Thu, 29 Apr 2021 10:49:24 +0200 From: Wolfgang Bumiller To: Dietmar Maurer Cc: Proxmox Backup Server development discussion Message-ID: <20210429084924.e3qqeahjgamnmbsu@wobu-vie.proxmox.com> References: <20210422140213.30989-1-w.bumiller@proxmox.com> <20210422140213.30989-6-w.bumiller@proxmox.com> <20210429070110.7pngjgt4656nuyln@wobu-vie.proxmox.com> <20210429071414.3ufaqkjclbpgwnxy@wobu-vie.proxmox.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: NeoMutt/20180716 X-SPAM-LEVEL: Spam detection results: 0 AWL 0.030 Adjusted score from AWL reputation of From: address KAM_DMARC_STATUS 0.01 Test Rule for DKIM or SPF Failure with Strict Alignment SPF_HELO_NONE 0.001 SPF: HELO does not publish an SPF Record SPF_PASS -0.001 SPF: sender matches SPF record Subject: Re: [pbs-devel] [PATCH v2 backup 05/27] CertInfo: add not_{after, before}_unix X-BeenThere: pbs-devel@lists.proxmox.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: Proxmox Backup Server development discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Apr 2021 08:49:26 -0000 On Thu, Apr 29, 2021 at 10:33:06AM +0200, Dietmar Maurer wrote: > > On 4/29/21 9:14 AM, Wolfgang Bumiller wrote: > > On Thu, Apr 29, 2021 at 09:08:03AM +0200, Dietmar Maurer wrote: > > > On 4/29/21 9:01 AM, Wolfgang Bumiller wrote: > > > > On Thu, Apr 29, 2021 at 08:13:19AM +0200, Dietmar Maurer wrote: > > > > > Seems I can do it without foreign-types: > > > > > > > > > > fn asn1_time_to_unix(time: &openssl::asn1::Asn1TimeRef) -> Result > > > > Error> { > > > > >     let epoch0 = openssl::asn1::Asn1Time::from_unix(0)?; > > > > >     let diff = epoch0.diff(time)?; > > > > >     let seconds = (diff.days as i64) * 24*60*60 + (diff.secs as i64); > > > > >     Ok(seconds) > > > > > } > > > > > > > > > > Any objections? > > > > Yes, for 2 reasons: > > > > * openssl does provide the functionality and the dependency is already > > > > in our tree because openssl pulls it in > > > > * 1100 days in already covers 3 leap seconds and I don't want to worry > > > > about whether `diff.days` takes that into account, the best time math > > > > is no time math at all > > > Agreed, but your code is unsafe and hard to read. IMHO that whole > > > foreign_type thing is hard to understand. And Unix Epoch does not care about > > > leap seconds, so why should we do? > > Because the diff method doesn't give you a unix epoch, it gives you a > > number of days without context which originally come from calendar > > dates, and this way days aren't well-enough defined for my taste. > > Beside, it seems we do not need those methods at all if we return the tlme > as String in the API. I disagree. On the one hand, the API is basically the same as PVE & PMG and is what the GUI expects (since we use the same components). On the other hand, IMO it makes more sense if a client can just take a timestamp and display it in *their* local time zone. Having to first parse the string output is weird, APIs are supposed to be simple, the interfacing-with-a-human part is the UI's job.