Re: [S-mailx] bad timestamp in case of gmtoff%60!=0
Arne Wörner wrote in : |On 2022-08-01T16:37:16TAI, Steffen Nurpmeso wrote: |> So why don't you come over with something understandable directly. |> |I thought i did... https://mailarchive.ietf.org/arch/msg/emailcore/OEwxOYEabI518_0m7r9vO57O0HI/ I will implement that, thanks for the report! (Currently busy, will report back once done!) Ciao --steffen | |Der Kragenbaer,The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt)
Re: [S-mailx] bad timestamp in case of gmtoff%60!=0
On 2022-08-01T16:37:16TAI, Steffen Nurpmeso wrote: > So why don't you come over with something understandable directly. > I thought i did... > What has %60 to do with it? > tm_gmtoff is the GMT offset in seconds... So tm_gmtoff%60 shows u, if there is a fraction of a minute in that offset... > So what you made the exim people do is that you force > interpretation of the local time as UTC if local seconds and UTC > seconds differ? But this is surely wrong, > No... > since any timezone can do so potentially! > Unlikely... TAI is the only zoneinfo I know of that does that... u can test that with this command: % TZ=MET date +%::z there should be a double O in the end... > $ grep -E '[[:digit:]+:[[:digit:]]+:[[:digit:]]+' \ > /usr/share/zoneinfo/tzdata.zi | wc -l > 624 > I dont know what that is... There is no tzdata.zi on my box... And it is very unlikely that 624 zoneinfos have a GMT offset that makes the RFC5322 timestamps incorrect. The people would have told you before... most likely... -arne
Re: [S-mailx] bad timestamp in case of gmtoff%60!=0
Hi Steffen.
On 2022-08-01T15:02:29TAI, Steffen Nurpmeso wrote:
> And localtime(3), on Linux, usually works according to /etc/localtime.
>
And localtime() fills a struct tm,
which has tm_gmtoff,
which contains fractions of a minute in my case (tm_gmtoff%60 equals 37
currently),
which RFC5322 cannot represent,
because it does not want to show the GMT offset accurately enough...
example:
% cat a.c
#include
#include
int main() {
time_t now = time(0);
struct tm * t;
t = localtime();
printf("localtime: gmtoff:%d gmtoff%60:%d\n", t->tm_gmtoff,
t->tm_gmtoff%60);
t = gmtime();
printf("gmtime: gmtoff:%d gmtoff%60:%d\n", t->tm_gmtoff,
t->tm_gmtoff%60);
return 0;
}
% c++ -o a a.c -O3
% ./a
localtime: gmtoff:37 gmtoff%60:37
gmtime: gmtoff:0 gmtoff%60:0
> How should i detect this?
>
U could check if gmtoff%60 is non-zero after a localtime() call,
and
if yes, then u switch to gmtime, which should do the trick.
> So then. And exim fits that perfect environment?
>
exim handles this situation properly now, I think...
https://bugs.exim.org/show_bug.cgi?id=2530
-arne
Re: [S-mailx] bad timestamp in case of gmtoff%60!=0
Hello Arne. ..but on the list is better indeed. Arne Wörner wrote in : |On 2022-07-28T17:15:02TAI, Steffen Nurpmeso wrote: |>|when I send an email with /bin/mail at 2022-07-28T04:48:54+00:00:37, |>|then s-mailx writes: |>|Date: Thu, 28 Jul 2022 04:48:54 + |> |> And what did you expect? |> |exim would convert the timestamp to UTC and |write "Date: Thu, 28 Jul 2022 04:48:17 +"... Well .. i had to look, but i hardly can imagine that exim applies any special massage there. You normally use the standard functions gmtime(3) and localtime(3) for these things, or you link against a special library which does such, i *think* ICU offers data and time conversion too, but i only looked a little bit, and a decade has passed since. And localtime(3), on Linux, usually works according to /etc/localtime. |> What is it that i should fix? |> |I would find it cool, if s-mailx could detect that situation itself. |But of course I can use my wrapper script, too... |The question is, if s-mailx should mention, |that it cannot produce an RFC5322-compliant timestamp in the TAI zone. How should i detect this? We use the localtime(3) function for local time, and the gmtime(3) function for GMT. Doing this all on our own is a very hard thing to do, you need to be able to parse all forms of the $TZ environment variable, and you need to get a portable notion of where to get the zone name from otherwise (like readlink(2) /etc/localtime). Apart from that i personally am total opposed to dropping leap seconds and solar time. CLOCK_TAI for programming purposes ok, but a TAI time zone? I do not even own a watch. |> If it is that you want some standard to include CLOCK_TAI, oh yes, |> that i would love to see myself. Much better than fiddling around |> with the link of civil time to solar time. But CLOCK_TAI is not |> that widely supported, nor are the mechanisms in the kernel |> everywhere. :( |> |We do not need CLOCK_TAI... Better it would be. |I think my zoneinfo file makes fiddling around with 61-second long \ |minutes unnecessary, |because: There are no such minutes in TAI zone... So then. And exim fits that perfect environment? --steffen | |Der Kragenbaer,The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt)
Re: [S-mailx] bad timestamp in case of gmtoff%60!=0
Hi Steffen! On 2022-07-28T17:15:02TAI, Steffen Nurpmeso wrote: > |when I send an email with /bin/mail at 2022-07-28T04:48:54+00:00:37, > |then s-mailx writes: > |Date: Thu, 28 Jul 2022 04:48:54 + > > And what did you expect? > exim would convert the timestamp to UTC and write "Date: Thu, 28 Jul 2022 04:48:17 +"... > What is it that i should fix? > I would find it cool, if s-mailx could detect that situation itself. But of course I can use my wrapper script, too... The question is, if s-mailx should mention, that it cannot produce an RFC5322-compliant timestamp in the TAI zone. > If it is that you want some standard to include CLOCK_TAI, oh yes, > that i would love to see myself. Much better than fiddling around > with the link of civil time to solar time. But CLOCK_TAI is not > that widely supported, nor are the mechanisms in the kernel > everywhere. :( > We do not need CLOCK_TAI... I think my zoneinfo file makes fiddling around with 61-second long minutes unnecessary, because: There are no such minutes in TAI zone... Bye Arne
