On Sat, 11 May 2019 00:30:35 +0200, Ingo Schwarze wrote:
> While here, i noticed ugly preprocessor macros.
> Let's make our future life easier by unifdefing a bit.
> When compiling with -g0, there is no object change.
No objection, OK millert@
- todd
Hi,
> That one looks correct. OK millert@
Committed, thanks for checking!
While here, i noticed ugly preprocessor macros.
Let's make our future life easier by unifdefing a bit.
When compiling with -g0, there is no object change.
Note that if TM_ZONE is not defined, wcsftime.c doesn't
currentl
On Fri, 10 May 2019 23:06:21 +0200, Ingo Schwarze wrote:
> The following patch preserves the parsing behaviour
> and correctly stores the number of seconds into tm_gmtoff.
That one looks correct. OK millert@
- todd
Ingo Schwarze wrote:
> Ouch. No, it does not. Thanks for spotting the regression.
>
> The following patch preserves the parsing behaviour
> and correctly stores the number of seconds into tm_gmtoff.
oops, missed that case too. this looks correct.
Hi Todd,
Todd C. Miller wrote on Fri, May 10, 2019 at 02:08:45PM -0600:
> On Fri, 10 May 2019 16:52:35 +0200, Ingo Schwarze wrote:
>> Here is a patch to fix the code.
> OK millert@ for that part.
Thanks, committed.
>> The change to %Z is exactly what Hiltjo sent.
>> The current code for %z is
On Fri, 10 May 2019 16:52:35 +0200, Ingo Schwarze wrote:
> I failed to find any users that do *not* expect seconds.
> So my conclusion is that the documentation is right and
> what the code in strptime.c does is wrong.
Yes, tm_gmtoff is in seconds.
> Here is a patch to fix the code.
OK millert@
Ingo Schwarze wrote:
> Now let's get to the more serious part.
> Hiltjo observed that %Z and %z produce wrong results.
>
> First of all, neither POSIX nor XPG define tm_gmtoff nor %Z nor %z:
>
> https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/time.h.html
> https://pubs.opengroup.org
Hi Ted,
Ted Unangst wrote on Thu, May 09, 2019 at 04:16:40PM -0400:
> Ingo Schwarze wrote:
>> I'm not mixing anything else into this diff. The other bugs should
>> be handled separately.
> Works for me. (with additional comment removal)
Thanks for checking, committed.
Now let's get to the mo
Ingo Schwarze wrote:
> I'm not mixing anything else into this diff. The other bugs should
> be handled separately.
>
> OK?
Works for me. (with additional comment removal)
On Thu, May 09, 2019 at 08:38:43PM +0200, Ingo Schwarze wrote:
> Hi,
>
> Theo de Raadt wrote on Sun, Mar 24, 2019 at 12:48:03PM -0600:
> > Hiltjo Posthuma wrote:
> >> On Sun, Feb 24, 2019 at 01:11:39PM +0100, Hiltjo Posthuma wrote:
>
> >>> 2. The military/nautical UTC offsets are [...]
>
> brok
Hi,
Theo de Raadt wrote on Sun, Mar 24, 2019 at 12:48:03PM -0600:
> Hiltjo Posthuma wrote:
>> On Sun, Feb 24, 2019 at 01:11:39PM +0100, Hiltjo Posthuma wrote:
>>> 2. The military/nautical UTC offsets are [...]
broken by design.
>> As discussed previously for point 2 I think it is fine to eithe
My position is we should delete support.
Hiltjo Posthuma wrote:
> On Sun, Feb 24, 2019 at 01:11:39PM +0100, Hiltjo Posthuma wrote:
> > Hi,
> >
> > I noticed some things in the strptime(3) implementing when parsing timezone
> > strings using the %z format string.
> >
> > 1. I noticed the tm_gmto
On Sun, Feb 24, 2019 at 01:11:39PM +0100, Hiltjo Posthuma wrote:
> Hi,
>
> I noticed some things in the strptime(3) implementing when parsing timezone
> strings using the %z format string.
>
> 1. I noticed the tm_gmtoff value is not correctly set in some cases. It should
> set tm_gmtoff to the of
On Sun, Mar 17, 2019 at 03:10:04PM -0400, Ted Unangst wrote:
> Hiltjo Posthuma wrote:
> > Not all BSD man pages reference the same RFCs, like RFC5322. The OpenBSD
> > strptime(3) man page (%z) describes military/nautical zones are supported.
> >
> > - NetBSD supports it (correctly since only a few
Hiltjo Posthuma wrote:
> Not all BSD man pages reference the same RFCs, like RFC5322. The OpenBSD
> strptime(3) man page (%z) describes military/nautical zones are supported.
>
> - NetBSD supports it (correctly since only a few months ago and it is not in
> stable or backported).
> - FreeBSD and
On Sun, Mar 10, 2019 at 04:16:37PM -0400, Ted Unangst wrote:
> Hiltjo Posthuma wrote:
> > 2. The military/nautical UTC offsets are also reversed. This was also
> > actually
> > a bug in RFC822:
> >
> > RFC5322 (referenced in strptime(3) man page):
> > https://tools.ietf.org/html/rfc5322
> > Secti
On Sun, Mar 03, 2019 at 09:01:58PM +0100, Hiltjo Posthuma wrote:
> On Sun, Feb 24, 2019 at 01:11:39PM +0100, Hiltjo Posthuma wrote:
> > Hi,
> >
> > I noticed some things in the strptime(3) implementing when parsing timezone
> > strings using the %z format string.
> >
> > 1. I noticed the tm_gmtof
On Sun, Feb 24, 2019 at 01:11:39PM +0100, Hiltjo Posthuma wrote:
> Hi,
>
> I noticed some things in the strptime(3) implementing when parsing timezone
> strings using the %z format string.
>
> 1. I noticed the tm_gmtoff value is not correctly set in some cases. It should
> set tm_gmtoff to the of
Hi,
I noticed some things in the strptime(3) implementing when parsing timezone
strings using the %z format string.
1. I noticed the tm_gmtoff value is not correctly set in some cases. It should
set tm_gmtoff to the offset from UTC in seconds (as described in mktime(3)).
2. The military/nautical
19 matches
Mail list logo
