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)
So here is a diff to delete support for the military time zones.
> Just error out when encountering them. That's the best thing we
> can do because their meaning is ill-defined in the first place.
>
> I'm not mixing anything else
e their meaning is ill-defined in the first place.
I'm not mixing anything else into this diff. The other bugs should
be handled separately.
OK?
Ingo
Index: strptime.3
===
RCS file: /cvs/src/lib/libc/time/strptime.3,v
retri
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
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
>
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
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 backporte
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):
> &
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
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
>
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
strptime reads strings, it doesn't write them.
Index: strptime.3
===
RCS file: /home/tedu/cvs/src/lib/libc/time/strptime.3,v
retrieving revision 1.12
diff -u -r1.12 strptime.3
--- strptime.3 19 Oct 2008 11:50:35 -
20 matches
Mail list logo
