Valery Ushakov wrote in
:
|On Fri, Dec 08, 2023 at 01:32:49 +0300, Valery Ushakov wrote:
|
|> On Thu, Dec 07, 2023 at 20:13:37 +, Robert Elz wrote:
|>
|>> While here, consistemntly use minus when minus is meant, rather that
|>> just using a hyphen.
|>
|> One has to be careful with this
On Fri, Dec 08, 2023 at 01:32:49 +0300, Valery Ushakov wrote:
> On Thu, Dec 07, 2023 at 20:13:37 +, Robert Elz wrote:
>
> > While here, consistemntly use minus when minus is meant, rather that
> > just using a hyphen.
>
> One has to be careful with this.
And to have this on record for refernc
On Thu, Dec 07, 2023 at 20:13:37 +, Robert Elz wrote:
> While here, consistemntly use minus when minus is meant, rather that
> just using a hyphen.
One has to be careful with this. In the literal context (Ql, Li, etc)
the ascii minus-hyphen in the input is preserved as such. In other
contex
Date:Wed, 26 Oct 2022 10:42:15 -0400
From:Jan Schaumann
Message-ID:
| New proposal:
That looks better (it needs some minor wording changes,
there are too many indefinite articles ('a') which aren't
needed, and there midnight should be just that, no hyphen
or space
Robert Elz wrote:
> Date:Sun, 23 Oct 2022 13:53:01 -0400
> From:Jan Schaumann
> Message-ID:
>
> | Hmm, maybe something like this?
>
> I think there is still too much there, you don't have
> to explain everything (or almost anything), but it is
> in the right dire
Taylor R Campbell wrote in
<20221023170035.2542f60...@jupiter.mumble.net>:
...
|If you use a monotonic timer to sample the POSIX clock before and
|after a leap second, the POSIX clock will appear to have taken twice
|as long as it should to pass the leap second.
Just to note that the next lea
Date:Sun, 23 Oct 2022 13:53:01 -0400
From:Jan Schaumann
Message-ID:
| Hmm, maybe something like this?
I think there is still too much there, you don't have
to explain everything (or almost anything), but it is
in the right direction I think.
| For example, cons
On Sun, Oct 23, 2022 at 11:00 AM Taylor R Campbell <
campbell+netbsd-source-change...@mumble.net> wrote:
> > Date: Sun, 23 Oct 2022 07:39:25 -0600
> > From: Warner Losh
> >
> > I guess a more accurate way of saying this is that leap seconds simply
> > aren't reliable, cannot be made reliable, and
> Date: Sun, 23 Oct 2022 12:19:37 -0600
> From: Warner Losh
>
> You must have a table of all past
> leap seconds to do any kind of sensible mapping. And you also must
> have some way to keep that up to date, [...]
It's the same for all civil calendar matters
Robert Elz wrote:
> Date:Sat, 22 Oct 2022 13:42:54 -0400
> From:Jan Schaumann
> Message-ID:
>
> | A full set of examples strikes me as too much here
>
> A full set would be yes, but I think we could handle 3.
Hmm, maybe something like this?
...and will be
> Date: Sun, 23 Oct 2022 07:39:25 -0600
> From: Warner Losh
>
> I guess a more accurate way of saying this is that leap seconds simply
> aren't reliable, cannot be made reliable, and this affects normalization
> in ways too numerous to mention due to the details of the tz files, bugs
> in the sys
On Sat, Oct 22, 2022 at 10:55 PM Robert Elz wrote:
> Date:Sat, 22 Oct 2022 20:17:57 -0600
> From:Warner Losh
> Message-ID: <
> canczdfqhkz0xs7lf6lmjveontc5dgsonons_ug6fzsf30og...@mail.gmail.com>
>
>
> | On the other hand, adding a caveat that leap seconds don't exi
On Sat, Oct 22, 2022, 8:05 PM Robert Elz wrote:
> Date:Sat, 22 Oct 2022 13:42:54 -0400
> From:Jan Schaumann
> Message-ID:
>
> | A full set of examples strikes me as too much here
>
> A full set would be yes, but I think we could handle 3.
> They don't need to be C
Date:Sat, 22 Oct 2022 20:17:57 -0600
From:Warner Losh
Message-ID:
| On the other hand, adding a caveat that leap seconds don't exist in a POSIX
| time_t and that's necessarily reflected in the normalization wouldn't be
| bad.
The problem with doing that is t
Date:Sun, 23 Oct 2022 08:33:18 +0700
From:Robert Elz
Message-ID: <7638.1666488...@jacaranda.noi.kre.to>
| and tm_min was incremented as tm_min+=180, and then
| mktime() called upon the result, the struct tm would
| now have tm_min==1 tm_hour==24 and tm_mday==20,
Date:Sat, 22 Oct 2022 13:42:54 -0400
From:Jan Schaumann
Message-ID:
| A full set of examples strikes me as too much here
A full set would be yes, but I think we could handle 3.
They don't need to be C code examples, just something
like
if tm_year==2022 tm_
Robert Elz wrote:
> jo...@bec.de said:
> | I'd actually weasle out a bit
>
> Yes, I would too, but
A full set of examples strikes me as too much here
still, and I do like the idea of weaseling out.
Perhaps:
This normalization is done in order from tm_sec up to
tm_year, possibly leading to ca
Date:Fri, 21 Oct 2022 15:00:41 -0400
From:Jan Schaumann
Message-ID:
| I believe that it's useful for people to know that
| values outside the normal ranges are normalized,
Agreed.
| as well as what that might look like.
The problem with trying to specify tha
Am Fri, Oct 21, 2022 at 02:06:32PM +0700 schrieb Robert Elz:
> Date:Fri, 21 Oct 2022 03:05:15 +
> From:"Jan Schaumann"
> Message-ID: <20221021030515.cdc9df...@cvs.netbsd.org>
>
> | Note normalizing behavior of mktime(3) using language from FreeBSD.
>
> If we ar
Robert Elz wrote:
> Date:Fri, 21 Oct 2022 11:54:08 -0400
> From:Jan Schaumann
> Message-ID:
>
> | Right, but all that strikes me as too much to put into
> | the manual page here.
>
> I agree, which is why I wondered if we should be giving any
> details about ho
Date:Fri, 21 Oct 2022 11:54:08 -0400
From:Jan Schaumann
Message-ID:
| Right, but all that strikes me as too much to put into
| the manual page here.
I agree, which is why I wondered if we should be giving any
details about how it is done at all.
| I think wha
Robert Elz wrote:
> Date:Fri, 21 Oct 2022 10:36:23 -0400
> From:Jan Schaumann
> Message-ID:
>
>
> | Perhaps like this?
>
> Like that, yes, but as you wrote it isn't how it is actually
> done I believe.
>
> The order looks to be secs, mins, hours, month, day(of
Date:Fri, 21 Oct 2022 10:36:23 -0400
From:Jan Schaumann
Message-ID:
| Perhaps like this?
Like that, yes, but as you wrote it isn't how it is actually
done I believe.
The order looks to be secs, mins, hours, month, day(of month).
There's no normalisation of the
Robert Elz wrote:
> Date:Fri, 21 Oct 2022 03:05:15 +
> From:"Jan Schaumann"
> Message-ID: <20221021030515.cdc9df...@cvs.netbsd.org>
>
> | Note normalizing behavior of mktime(3) using language from FreeBSD.
>
> If we are going to start specifying what happens (
Date:Fri, 21 Oct 2022 03:05:15 +
From:"Jan Schaumann"
Message-ID: <20221021030515.cdc9df...@cvs.netbsd.org>
| Note normalizing behavior of mktime(3) using language from FreeBSD.
If we are going to start specifying what happens (how the struct tm
is normalised)
In article <977b81a4-d330-6722-7ce4-cc4e61011...@gmx.de>,
Roland Illig wrote:
>Am 25.03.2022 um 22:25 schrieb Christos Zoulas:
>> In article <20220325183551.0f039f...@cvs.netbsd.org>,
>> Roland Illig wrote:
>>> -=-=-=-=-=-
>>>
>>> Module Name:src
>>> Committed By: rillig
>>> Date:
Am 26.03.2022 um 00:50 schrieb Tobias Nygren:
On Sat, 26 Mar 2022 00:31:45 +0100
Roland Illig wrote:
localtime.c: add back storage class 'register'
This reduces the differences to the upstream code.
I don't know why you did that. It is as simple to sed -e 's/register //g'
in upstream when y
On Sat, 26 Mar 2022 00:31:45 +0100
Roland Illig wrote:
> >> localtime.c: add back storage class 'register'
> >>
> >> This reduces the differences to the upstream code.
> >
> > I don't know why you did that. It is as simple to sed -e 's/register //g'
> > in upstream when you diff. Adding register
Am 25.03.2022 um 22:25 schrieb Christos Zoulas:
In article <20220325183551.0f039f...@cvs.netbsd.org>,
Roland Illig wrote:
-=-=-=-=-=-
Module Name:src
Committed By: rillig
Date: Fri Mar 25 18:35:50 UTC 2022
Modified Files:
src/lib/libc/time: localtime.c
Log Message:
lo
In article ,
Roland Illig wrote:
>
>The mess with the indentation comes from upstream. In our copy it's a
>bit worth than upstream, but not much.
I've asked upstream to indent consistently in the past. It has not happened.
I try to minimize the diffs with upstream so that we can keep patching i
In article <20220325183551.0f039f...@cvs.netbsd.org>,
Roland Illig wrote:
>-=-=-=-=-=-
>
>Module Name: src
>Committed By: rillig
>Date: Fri Mar 25 18:35:50 UTC 2022
>
>Modified Files:
> src/lib/libc/time: localtime.c
>
>Log Message:
>localtime.c: add back storage class 'register'
In article <20220325190016.15114f...@cvs.netbsd.org>,
Roland Illig wrote:
>-=-=-=-=-=-
>
>Module Name: src
>Committed By: rillig
>Date: Fri Mar 25 19:00:16 UTC 2022
>
>Modified Files:
> src/lib/libc/time: localtime.c
>
>Log Message:
>localtime.c: take indentation style from upstr
Am 25.03.2022 um 13:59 schrieb Robert Elz:
Date:Thu, 24 Mar 2022 23:32:30 +0100
From:Roland Illig
Message-ID: <6bb00924-edaf-a4c8-348e-ba1304d57...@gmx.de>
| Someone should clean up this mess.
No, they probabky shouldn't, in general.
That source comes from t
Date:Thu, 24 Mar 2022 23:32:30 +0100
From:Roland Illig
Message-ID: <6bb00924-edaf-a4c8-348e-ba1304d57...@gmx.de>
| Someone should clean up this mess.
No, they probabky shouldn't, in general.
That source comes from the tz project (currently from
tzcode2022a) with l
Am 24.03.2022 um 17:15 schrieb Christos Zoulas:
Module Name:src
Committed By: christos
Date: Thu Mar 24 16:15:05 UTC 2022
Modified Files:
src/lib/libc/time: localtime.c
Log Message:
put back the 2022a changes and fix the misplaced brace.
To generate a diff of this comm
On Wed, Mar 23, 2022 at 02:00:29PM +0100, Tobias Nygren wrote:
> I think this commit broke something.
> date(1) no longer reports a time zone and is stuck at GMT time:
>
> $ ls -l /etc/localtime
> lrwxr-xr-x 1 root wheel 36 Mar 22 08:47 /etc/localtime ->
> /usr/share/zoneinfo/Europe/Stockholm
On Tue, 22 Mar 2022 13:48:39 -0400
Christos Zoulas wrote:
> Modified Files:
> src/lib/libc/time: CONTRIBUTING Makefile NEWS localtime.c private.h
> theory.html tz-link.html tzselect.8 tzselect.ksh version zdump.c
> zic.c
>
> Log Message:
> welcome to tzcode-2022a
Hi,
On Apr 18, 11:26am, p...@whooppee.com (Paul Goyette) wrote:
-- Subject: Re: CVS commit: src/lib/libc/time
| Here's round 2 - let me know if this is acceptable:
Yup, that looks fine. Thanks!
christos
|
| Index: tzset.3
| ===
Date:Wed, 17 Apr 2019 22:47:04 -0400
From:chris...@zoulas.com (Christos Zoulas)
Message-ID: <20190418024704.6a10717f...@rebar.astron.com>
| Put it as part of the documentation and say that it is a bug that there
| is no way to get one referencing a particular point
On Apr 18, 10:07am, p...@whooppee.com (Paul Goyette) wrote:
-- Subject: Re: CVS commit: src/lib/libc/time
| Here's a draft. If there's no objection, I can commit it in a day or
| two.
Put it as part of the documentation and say that it is a bug that there
is no way to get one ref
On Wed, 17 Apr 2019, Christos Zoulas wrote:
On Apr 18, 10:07am, p...@whooppee.com (Paul Goyette) wrote:
-- Subject: Re: CVS commit: src/lib/libc/time
| Here's a draft. If there's no objection, I can commit it in a day or
| two.
Put it as part of the documentation and say that i
On Apr 18, 9:57am, p...@whooppee.com (Paul Goyette) wrote:
-- Subject: Re: CVS commit: src/lib/libc/time
| >> XXX: To be strictly correct, the tzgetname() call should probably take
| >> a time reference point in order to return the appropriate zone name
| >> for the time given
On Thu, 18 Apr 2019, Paul Goyette wrote:
XXX: To be strictly correct, the tzgetname() call should probably take
a time reference point in order to return the appropriate zone name
for the time given.
Yes, the timezone name should be associated with the specific point in
time.
Of course, the
XXX: To be strictly correct, the tzgetname() call should probably take
a time reference point in order to return the appropriate zone name
for the time given.
Yes, the timezone name should be associated with the specific point in
time.
Of course, the problem is, what specific point in time sho
Module Name:src
Committed By: christos
Date: Wed Apr 17 17:37:29 UTC 2019
Modified Files:
src/lib/libc/time: localtime.c
Log Message:
Pick up the latest matching (most recent) entry instead of the first
one.
This fixes:
env TZ=Australia/Melbourne date
printing
Date:Sun, 29 Oct 2017 22:55:35 +0530
From:Abhinav Upadhyay
Message-ID:
| While mandoc -Tlint is not complaining about this, but it isn't
| working as expected (I don't see any dash in the rendered output).
You mean if you add the .ie/.el lines to the source?
On Sun, Oct 29, 2017 at 9:55 PM, Robert Elz wrote:
> Date:Sun, 29 Oct 2017 06:07:48 +
> From:"Abhinav Upadhyay"
> Message-ID: <20171029060748.45c43f...@cvs.netbsd.org>
>
> | Modified Files:
> | src/lib/libc/time: time2posix.3
> |
> | Log Message:
> |
Date:Sun, 29 Oct 2017 06:07:48 +
From:"Abhinav Upadhyay"
Message-ID: <20171029060748.45c43f...@cvs.netbsd.org>
| Modified Files:
| src/lib/libc/time: time2posix.3
|
| Log Message:
| Fix the escape used for em dash
It was intended to be an n-dash (n
On Mar 22, 2:51pm, ginsb...@netbsd.org (Brian Ginsbach) wrote:
-- Subject: Re: CVS commit: src/lib/libc/time
| On Fri, Mar 18, 2016 at 02:02:21PM +, Christos Zoulas wrote:
| > In article <20160318124125.42d61f...@cvs.netbsd.org>,
| > Brian Ginsbach wrote:
| > >-=-=-=-=-=-
On Fri, Mar 18, 2016 at 02:02:21PM +, Christos Zoulas wrote:
> In article <20160318124125.42d61f...@cvs.netbsd.org>,
> Brian Ginsbach wrote:
> >-=-=-=-=-=-
> >
> >Module Name: src
> >Committed By:ginsbach
> >Date:Fri Mar 18 12:41:25 UTC 2016
> >
> >Modified Files:
> >
In article <20160318124125.42d61f...@cvs.netbsd.org>,
Brian Ginsbach wrote:
>-=-=-=-=-=-
>
>Module Name: src
>Committed By: ginsbach
>Date: Fri Mar 18 12:41:25 UTC 2016
>
>Modified Files:
> src/lib/libc/time: localtime.c
>
>Log Message:
>Use the correct upper bounds for the types
"Brian Ginsbach"
writes:
> Module Name: src
> Committed By: ginsbach
> Date: Fri Oct 30 01:49:36 UTC 2015
>
> Modified Files:
> src/lib/libc/time: strptime.c
>
> Log Message:
> Reject timezone offsets more than 12 hours (east or west).
WTF?? There exist (or existed) zones +13 and
Paul Goyette wrote:
|Just to show how complicated the subject of timezones really is, here
|are a couple of interesting quotes from the wikipedia article on
|International Date Line
Oh i'm prowd of my Timezone, but the code which uses this clean
thing is one of the worst things.
I haven't see
On Thu, Oct 29, 2015 at 10:27:48PM -0600, Warner Losh wrote:
> On Thu, Oct 29, 2015 at 9:06 PM, Brian Ginsbach wrote:
>
> > On Thu, Oct 29, 2015 at 06:38:48PM -0800, Warner Losh wrote:
> > >
> > > > On Oct 29, 2015, at 8:06 PM, Robert Elz wrote:
> > > >
> > > >Date:Fri, 30 Oct 2015 0
Hi,
"Brian Ginsbach" wrote:
|Module Name: src
|Committed By: ginsbach
|Date: Fri Oct 30 01:49:36 UTC 2015
|
|Modified Files:
| src/lib/libc/time: strptime.c
|
|Log Message:
|Reject timezone offsets more than 12 hours (east or west).
i saw this, but i definetely remember offs
Just to show how complicated the subject of timezones really is, here
are a couple of interesting quotes from the wikipedia article on
International Date Line
Two uninhabited atolls, Howland Island and Baker Island, just
north of the equator in the central Pacific Ocean (and shi
On Thu, Oct 29, 2015 at 9:06 PM, Brian Ginsbach wrote:
> On Thu, Oct 29, 2015 at 06:38:48PM -0800, Warner Losh wrote:
> >
> > > On Oct 29, 2015, at 8:06 PM, Robert Elz wrote:
> > >
> > >Date:Fri, 30 Oct 2015 01:49:36 +
> > >From:"Brian Ginsbach"
> > >Message-ID:
> On Oct 29, 2015, at 8:06 PM, Robert Elz wrote:
>
>Date:Fri, 30 Oct 2015 01:49:36 +
>From:"Brian Ginsbach"
>Message-ID: <20151030014936.3fd4...@cvs.netbsd.org>
>
> | Reject timezone offsets more than 12 hours (east or west).
>
> That's definitely incorrect.
On Thu, Oct 29, 2015 at 06:38:48PM -0800, Warner Losh wrote:
>
> > On Oct 29, 2015, at 8:06 PM, Robert Elz wrote:
> >
> >Date:Fri, 30 Oct 2015 01:49:36 +
> >From:"Brian Ginsbach"
> >Message-ID: <20151030014936.3fd4...@cvs.netbsd.org>
> >
> > | Reject timezone
On Fri, Oct 30, 2015 at 09:06:11AM +0700, Robert Elz wrote:
> Date:Fri, 30 Oct 2015 01:49:36 +
> From:"Brian Ginsbach"
> Message-ID: <20151030014936.3fd4...@cvs.netbsd.org>
>
> | Reject timezone offsets more than 12 hours (east or west).
>
> That's definitely i
On Fri, 30 Oct 2015, Paul Goyette wrote:
On Fri, 30 Oct 2015, Paul Goyette wrote:
On Fri, 30 Oct 2015, Brian Ginsbach wrote:
Module Name:src
Committed By: ginsbach
Date: Fri Oct 30 01:49:36 UTC 2015
Modified Files:
src/lib/libc/time: strptime.c
Log Message:
Reject t
On Fri, Oct 30, 2015 at 10:03:23AM +0800, Paul Goyette wrote:
> On Fri, 30 Oct 2015, Brian Ginsbach wrote:
>
> >Module Name: src
> >Committed By:ginsbach
> >Date:Fri Oct 30 01:49:36 UTC 2015
> >
> >Modified Files:
> > src/lib/libc/time: strptime.c
> >
> >Log Message:
>
Date:Fri, 30 Oct 2015 01:49:36 +
From:"Brian Ginsbach"
Message-ID: <20151030014936.3fd4...@cvs.netbsd.org>
| Reject timezone offsets more than 12 hours (east or west).
That's definitely incorrect.
andromeda$ TZ=Pacific/Auckland date +"%c %z"
Fri Oct 30 15:04:0
On Fri, 30 Oct 2015, Paul Goyette wrote:
On Fri, 30 Oct 2015, Brian Ginsbach wrote:
Module Name:src
Committed By: ginsbach
Date: Fri Oct 30 01:49:36 UTC 2015
Modified Files:
src/lib/libc/time: strptime.c
Log Message:
Reject timezone offsets more than 12 hours (east or
On Fri, 30 Oct 2015, Brian Ginsbach wrote:
Module Name:src
Committed By: ginsbach
Date: Fri Oct 30 01:49:36 UTC 2015
Modified Files:
src/lib/libc/time: strptime.c
Log Message:
Reject timezone offsets more than 12 hours (east or west).
Why?
According to www.timeandda
On Wed, Jul 08, 2015 at 07:30:45PM +, Christos Zoulas wrote:
> In article <20150708184409.81c2...@cvs.netbsd.org>,
> Brian Ginsbach wrote:
> >-=-=-=-=-=-
> >
> >Module Name: src
> >Committed By:ginsbach
> >Date:Wed Jul 8 18:44:09 UTC 2015
> >
> >Modified Files:
> >
On Wed, Jul 08, 2015 at 11:46:57AM -0700, Hisashi T Fujinaka wrote:
> No commit message?
It was fixed shortly afterwards.
>
> On Wed, 8 Jul 2015, Brian Ginsbach wrote:
>
> >Module Name: src
> >Committed By:ginsbach
> >Date:Wed Jul 8 18:44:09 UTC 2015
> >
> >Modified Fi
In article <20150708184409.81c2...@cvs.netbsd.org>,
Brian Ginsbach wrote:
>-=-=-=-=-=-
>
>Module Name: src
>Committed By: ginsbach
>Date: Wed Jul 8 18:44:09 UTC 2015
>
>Modified Files:
> src/lib/libc/time: strptime.c
>
I thought about renaming too, but this just makes diffing
w
No commit message?
On Wed, 8 Jul 2015, Brian Ginsbach wrote:
Module Name:src
Committed By: ginsbach
Date: Wed Jul 8 18:44:09 UTC 2015
Modified Files:
src/lib/libc/time: strptime.c
To generate a diff of this commit:
cvs rdiff -u -r1.40 -r1.41 src/lib/libc/time/strptim
On Mon, Apr 06, 2015 at 07:10:27PM +0200, Alan Barrett wrote:
> On Mon, 06 Apr 2015, Brian Ginsbach wrote:
> >Module Name: src
> >Committed By:ginsbach
> >Date:Mon Apr 6 14:38:22 UTC 2015
> >
> >Modified Files:
> > src/lib/libc/time: strptime.3 strptime.c
> >
> >Log Mes
On Mon, 06 Apr 2015, Brian Ginsbach wrote:
Module Name:src
Committed By: ginsbach
Date: Mon Apr 6 14:38:22 UTC 2015
Modified Files:
src/lib/libc/time: strptime.3 strptime.c
Log Message:
Add UTC as a synonym for GMT (%Z). [from FreeBSD]
The %z format (which is distinc
In article <20140816123631.ga3...@apb-laptoy.apb.alt.za>,
Alan Barrett wrote:
>On Sat, 16 Aug 2014, Christos Zoulas wrote:
>>Module Name: src
>>Committed By: christos
>>Date: Sat Aug 16 10:38:43 UTC 2014
>>
>>Modified Files:
>> src/lib/libc/time: zic.c
>>
>> Log Message:
>> gcc on t
On Sat, 16 Aug 2014, Christos Zoulas wrote:
Module Name:src
Committed By: christos
Date: Sat Aug 16 10:38:43 UTC 2014
Modified Files:
src/lib/libc/time: zic.c
Log Message:
gcc on the sparc needs help with variables it thinks are
unitialized, but are not.
In article <20131226220940.ga24...@snowdrop.l8s.co.uk>,
David Laight wrote:
>On Thu, Dec 26, 2013 at 01:34:28PM -0500, Christos Zoulas wrote:
>> Module Name: src
>> Committed By:christos
>> Date:Thu Dec 26 18:34:28 UTC 2013
>...
>> f:
>> The types of the global variabl
On Thu, Dec 26, 2013 at 01:34:28PM -0500, Christos Zoulas wrote:
> Module Name: src
> Committed By: christos
> Date: Thu Dec 26 18:34:28 UTC 2013
...
> f:
> The types of the global variables 'timezone' and 'altzone' (if present)
> have been changed back to 'long'. This is required
Am 14.12.2013 um 12:32 schrieb Martin Husemann :
> On Fri, Dec 13, 2013 at 05:34:47AM -0500, Christos Zoulas wrote:
>> Module Name: src
>> Committed By:christos
>> Date:Fri Dec 13 10:34:47 UTC 2013
>>
>> Modified Files:
>> src/lib/libc/time: localtime.c
>>
>> Log Mes
On Fri, Dec 13, 2013 at 05:34:47AM -0500, Christos Zoulas wrote:
> Module Name: src
> Committed By: christos
> Date: Fri Dec 13 10:34:47 UTC 2013
>
> Modified Files:
> src/lib/libc/time: localtime.c
>
> Log Message:
> add a cast for sparc64 where int_fast32_t is long (should it be?
On Thu, 01 Aug 2013, David Holland wrote:
(I thought time_t was required to be an integer type, but I suppose
there's some legacy platform where it isn't.)
C99 requires time_t to be an arithmetic type.
C99 section 7.23.1 point 3 "The types declared are ... clock_t and
time_t which are
On Wed, Jul 31, 2013 at 09:53:28AM +0200, Alan Barrett wrote:
> >> Modified Files:
> >> src/lib/libc/time: localtime.c
> >>
> >> Log Message:
> >> Don't depend on implicit rounding from non-integral float constant.
> >
> >what on earth is that code trying to do?
>
> If time_t is a float
On Wed, 31 Jul 2013, David Holland wrote:
On Tue, Jul 30, 2013 at 03:30:37PM +, Joerg Sonnenberger wrote:
> Modified Files:
>src/lib/libc/time: localtime.c
>
> Log Message:
> Don't depend on implicit rounding from non-integral float constant.
what on earth is that code trying to do?
If
On Tue, Jul 30, 2013 at 03:30:37PM +, Joerg Sonnenberger wrote:
> Modified Files:
> src/lib/libc/time: localtime.c
>
> Log Message:
> Don't depend on implicit rounding from non-integral float constant.
...
what on earth is that code trying to do?
--
David A. Holland
dholl...@netb
On Thu, Oct 25, 2012 at 04:18:54PM +0200, Alan Barrett wrote:
> Does adding a /*CONSTCOND*/ comment work? If so, I'd prefer that
> to a cast. If you do need a cast, then I think you should cast
> dayoff to zic_t.
I backed it out and set NOGCCERROR instead - couldn't figure any way with
casts o
On Thu, 25 Oct 2012, Martin Husemann wrote:
Modified Files:
src/lib/libc/time: zic.c
Log Message:
Add a few casts to avoid (IMHO bogus) gcc warnings breaking the vax build.
- if (dayoff < min_time / SECSPERDAY) {
+ if (dayoff < (long)(min_time / SECSPERDAY)) {
time_t and
hi,
> On Feb 11, 11:47pm, y...@mwd.biglobe.ne.jp (YAMAMOTO Takashi) wrote:
> -- Subject: Re: CVS commit: src/lib/libc/time
>
> | hi,
> |
> | > Module Name: src
> | > Committed By: christos
> | > Date: Thu Jan 6 02:41:34 UTC 2011
> | >
On Feb 11, 11:47pm, y...@mwd.biglobe.ne.jp (YAMAMOTO Takashi) wrote:
-- Subject: Re: CVS commit: src/lib/libc/time
| hi,
|
| > Module Name:src
| > Committed By: christos
| > Date: Thu Jan 6 02:41:34 UTC 2011
| >
| > Modified Files:
| >
hi,
> Module Name: src
> Committed By: christos
> Date: Thu Jan 6 02:41:34 UTC 2011
>
> Modified Files:
> src/lib/libc/time: localtime.c
>
> Log Message:
> Since localsub and gmtsub are called recursively to search for the local
> time, setting EOVERFLOW at the inmost level will
> On Fri Dec 17 2010 at 18:11:57 -0500, Christos Zoulas wrote:
> > Module Name:src
> > Committed By: christos
> > Date: Fri Dec 17 23:11:57 UTC 2010
> >
> > Modified Files:
> > src/lib/libc/time: localtime.c
> >
> > Log Message:
> > PR/44248: Antti Kantee: Fix mult
On Fri Dec 17 2010 at 18:11:57 -0500, Christos Zoulas wrote:
> Module Name: src
> Committed By: christos
> Date: Fri Dec 17 23:11:57 UTC 2010
>
> Modified Files:
> src/lib/libc/time: localtime.c
>
> Log Message:
> PR/44248: Antti Kantee: Fix multi-threaded localtime hang.
Please r
On Sat, May 15, 2010 at 01:54:52PM +, Paul Goyette wrote:
> XXX Someone else can decide whether we should refer to "U.S.A." or to
> XXX "the United States" in the parenthetical.
The way it is now matches the other use later on, so let's leave it.
--
David A. Holland
dholl...@netbsd.org
On Mon, Dec 14, 2009 at 03:56:14PM +0100, Joerg Sonnenberger wrote:
> > - } while ((sse * 10 <= TIME_MAX) &&
> > + } while (((uint64_t)(sse * 10) <=
> > TIME_MAX) &&
> >
> > Don't you want ((uint64_t)sse * 10 <= TIME_MAX), that is,
On Mon, Dec 14, 2009 at 06:15:21AM +, David Holland wrote:
> On Mon, Dec 14, 2009 at 05:51:57AM +, Matt Thomas wrote:
> > Suppress a warning if time_t is __int64_t
>
> - } while ((sse * 10 <= TIME_MAX) &&
> + } while (((uint64_t)
On Mon, Dec 14, 2009 at 05:51:57AM +, Matt Thomas wrote:
> Suppress a warning if time_t is __int64_t
- } while ((sse * 10 <= TIME_MAX) &&
+ } while (((uint64_t)(sse * 10) <= TIME_MAX) &&
Don't you want ((uint64_t)sse * 10 <= TIME_MA
92 matches
Mail list logo
