From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <s.ivanov@proxmox.com>
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) server-digest SHA256)
(No client certificate requested)
by lists.proxmox.com (Postfix) with ESMTPS id E69D391120
for <pmg-devel@lists.proxmox.com>; Tue, 13 Feb 2024 15:54:41 +0100 (CET)
Received: from firstgate.proxmox.com (localhost [127.0.0.1])
by firstgate.proxmox.com (Proxmox) with ESMTP id C963237BE0
for <pmg-devel@lists.proxmox.com>; Tue, 13 Feb 2024 15:54:11 +0100 (CET)
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
for <pmg-devel@lists.proxmox.com>; Tue, 13 Feb 2024 15:54:10 +0100 (CET)
Received: from proxmox-new.maurer-it.com (localhost.localdomain [127.0.0.1])
by proxmox-new.maurer-it.com (Proxmox) with ESMTP id 87D7847CE8
for <pmg-devel@lists.proxmox.com>; Tue, 13 Feb 2024 15:54:10 +0100 (CET)
Date: Tue, 13 Feb 2024 15:54:09 +0100
From: Stoiko Ivanov <s.ivanov@proxmox.com>
To: Mira Limbeck <m.limbeck@proxmox.com>
Cc: pmg-devel@lists.proxmox.com
Message-ID: <20240213155409.61527821@rosa.proxmox.com>
In-Reply-To: <20230718160101.1070267-1-m.limbeck@proxmox.com>
References: <20230718160101.1070267-1-m.limbeck@proxmox.com>
X-Mailer: Claws Mail 4.1.1 (GTK 3.24.38; x86_64-pc-linux-gnu)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
X-SPAM-LEVEL: Spam detection results: 0
AWL 0.087 Adjusted score from AWL reputation of From: address
BAYES_00 -1.9 Bayes spam probability is 0 to 1%
DMARC_MISSING 0.1 Missing DMARC policy
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
T_SCC_BODY_TEXT_LINE -0.01 -
Subject: Re: [pmg-devel] [RFC log-tracker] rfc3339: move timezone offset
compatibility code to
X-BeenThere: pmg-devel@lists.proxmox.com
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Proxmox Mail Gateway development discussion
<pmg-devel.lists.proxmox.com>
List-Unsubscribe: <https://lists.proxmox.com/cgi-bin/mailman/options/pmg-devel>,
<mailto:pmg-devel-request@lists.proxmox.com?subject=unsubscribe>
List-Archive: <http://lists.proxmox.com/pipermail/pmg-devel/>
List-Post: <mailto:pmg-devel@lists.proxmox.com>
List-Help: <mailto:pmg-devel-request@lists.proxmox.com?subject=help>
List-Subscribe: <https://lists.proxmox.com/cgi-bin/mailman/listinfo/pmg-devel>,
<mailto:pmg-devel-request@lists.proxmox.com?subject=subscribe>
X-List-Received-Date: Tue, 13 Feb 2024 14:54:41 -0000
Thanks for the patch!
looks ok - but as talked off-list and also hinted in the api-patch reply I
sent - if possible we could maybe get rid of the issue that the
start+endtime provided in the GUI is interpreted differently than the
current option, which is yet again different to what I'd expect:
Testcase is '2023-09-21 13:52' as starttime '2023-09-21 15:00' as endtime
* with both patches applied the first mail shown is from 15:52 (offset +2h)
* with the currently released version the first mail is shown is from
14:52 (offset +1h)
* I personally would expect no offset ;)
potentially we could not consider the client's timezone too much - and
define that the results are based on the server's timezone (or more
correctly on what's actually written in the logs)
If we want to consider the timezone of the client we should account for DST
i.e. if the client is currently (in February) in CET, that they would've
been in CEST in September - but I think that might be quite too much of a
hassle - and the break of displaying one time in the information line vs.
another in the actual logs sounds confusing
please adapt the tests for the next version
two tiny nits inline:
On Tue, 18 Jul 2023 18:01:00 +0200
Mira Limbeck <m.limbeck@proxmox.com> wrote:
> old time format parsing code
if possible - get this information also into the subject line (70
character limit)
>
>..snip..
> @@ -2287,12 +2287,12 @@ fn parse_time_with_year(data: &'_ [u8], timezone_offset: time_t) -> Option<(time
> std::str::from_utf8_unchecked(×tamp_buffer[0..timestamp_len])
> }) {
> // TODO handle timezone offset in old code path instead
this patch fixes the TODO :) - get rid of it
> - Ok(ltime) => Some((ltime + timezone_offset, data)),
> + Ok(ltime) => Some((ltime, data)),
> Err(_err) => None,
> }
> }
>
> -fn parse_time_no_year(data: &'_ [u8], cur_year: i64, cur_month: i64) -> Option<(time_t, &'_ [u8])> {
> +fn parse_time_no_year(data: &'_ [u8], cur_year: i64, cur_month: i64, timezone_offset: time_t) -> Option<(time_t, &'_ [u8])> {
> if data.len() < 15 {
> return None;
> }
> @@ -2397,7 +2397,7 @@ fn parse_time_no_year(data: &'_ [u8], cur_year: i64, cur_month: i64) -> Option<(
> _ => &data[1..],
> };
>
> - Some((ltime, data))
> + Some((ltime - timezone_offset, data))
> }
>
> type ByteSlice<'a> = &'a [u8];