You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
g_mime_message_set_date() and g_mime_message_get_date() and g_mime_utils_header_decode_date() fail for TAI timezoneΒ #134
When I use this timezone file, and when I send an email @1658946095 (date -d@1658946095 = "Wed Jul 27 18:21:45 TAI 2022"), balsa says, that the timestamp is "2022-07-27T18:22:12TAI" (format: %FT%T%Z).
It seems like these functions do not behave like date(1), because: They just ignore the fractions of a minute (% 60) in tm_gmtoff.
Can you somehow fix it? I do not know why these functions do that... I just wanted to avoid those annoying leap seconds (once I thought that the crystal in my self-tinkered USB sensor phalanx is broken, when i woke up in the morning...)...
PS: Here is my bug report in the balsa issues list...
PPS: exim and s-mailx already switch to UTC and use "-0000" as timezone offset (the minus denotes a deviating time zone in accordance with RFC5322, if i understood correctly).
@jstedfast thanks for that patch... i have some comments:
line 236: "%c%05d" seems to be too long... it should be "%c%04d"... right?
line 232: and i do not see, how day,month,year,hour,min,sec change, when u only change tz_offset... maybe "g_date_time_add_seconds" could be used to subtract (or add) the old value of tz_offset? tz_offset = 0; sign = '-'; } return g_strdup_printf ("%s, %02d %s %04d %02d:%02d:%02d %c%05d",
i need to setup a build environment... is this the right way to go: git clone https://github.com/jstedfast/gmime.git ?
@jstedfast
I found another error in ur patch (%G_TIME_SPAN_SECOND would find sub second fractions...)...
But it still does not work... It seems like g_date_time_new_from_unix_local has a problem with my system time, too (it seems like it acts like my box does not know of leap seconds...)...
> balsa
ARNE g_mime_utils_header_format_date: time:1668421497 min:25 sec:34 tz:37000000/60000000
ARNE g_mime_utils_header_format_date: fracMIN min:24 sec:57
> date -d@1668421497
Mon Nov 14 10:25:07 TAI 2022
> TZ=UTC date -d@1668421497
Mon Nov 14 10:24:30 UTC 2022
@jstedfast how do g_date_time_get_second and g_date_time_new_from_unix_local work? I mean: Do they use the system routines? or do they try to circumvent the zoneinfo files?
it seems like GLib wants to circumvent the system routines with their own custom routines... i wonder if javascript also uses GLib, because: It has at least a similar problem... π
what about a RFC5322-compliance check, when gmime tries to make a human-readable timestamp?
Activity
Properly handle GDateTime UTC offsets with non-zero seconds
jstedfast commentedon Nov 13, 2022
I would appreciate if you could test this for me. I wrote this patch from my Windows development machine which makes it non-trivial to test this.
riddicc commentedon Nov 13, 2022
@jstedfast thanks for that patch... i have some comments:
line 236: "%c%05d" seems to be too long... it should be "%c%04d"... right?
line 232: and i do not see, how day,month,year,hour,min,sec change, when u only change tz_offset... maybe "g_date_time_add_seconds" could be used to subtract (or add) the old value of tz_offset?
tz_offset = 0; sign = '-'; } return g_strdup_printf ("%s, %02d %s %04d %02d:%02d:%02d %c%05d",i need to setup a build environment... is this the right way to go:
git clone https://github.com/jstedfast/gmime.git?riddicc commentedon Nov 14, 2022
@jstedfast
I found another error in ur patch (
%G_TIME_SPAN_SECONDwould find sub second fractions...)...But it still does not work... It seems like
g_date_time_new_from_unix_localhas a problem with my system time, too (it seems like it acts like my box does not know of leap seconds...)...this is the output of my test:
Properly handle GDateTime UTC offsets with non-zero seconds
jstedfast commentedon Nov 14, 2022
Thanks, I've made the corrections and folded them into my original patch (with a force push)..
jstedfast commentedon Nov 14, 2022
Interesting... C#/.NET does not allow timezones with non-0 seconds:
Result:
riddicc commentedon Nov 14, 2022
@jstedfast how do
g_date_time_get_secondandg_date_time_new_from_unix_localwork? I mean: Do they use the system routines? or do they try to circumvent the zoneinfo files?jstedfast commentedon Nov 14, 2022
You'd have to ask the GLib developers. I'm not sure how the internals of those functions work.
riddicc commentedon Nov 16, 2022
@jstedfast Uhm... Glib intentionally circumvents the system time routines and ignores POSIX...
can gmime take care of this, since it is talking to POSIX compliant systems?
I would recommend to use
gmtime(3) andlocaltime(3)...jstedfast commentedon Nov 16, 2022
Are things still not working? I don't understand why I need to bypass Glib's time routines now.
riddicc commentedon Nov 16, 2022
@jstedfast it seems like GLib still uses the original meaning of "seconds since 1970"... GLib acts like there are no leap seconds...
So gmime would have to use functions like strptime(3) and strftime(3) to be POSIX and RFC5322 compliant, i guess...
But maybe GLib changes its mind... i cant say that... I am ok with my balsa patch...
I just thought, that gmime or GLib might want to be leap seconds aware... π«£
riddicc commentedon Nov 30, 2022
it seems like GLib wants to circumvent the system routines with their own custom routines... i wonder if javascript also uses GLib, because: It has at least a similar problem... π
what about a RFC5322-compliance check, when gmime tries to make a human-readable timestamp?