> Also, not all versions of POSIX are equally good. I've found smoking gun
> bugs in some implementations of gmtime() and related.
Please put the details on a web page and tell us the URL.
--
These are my opinions. I hate spam.
___
LEAPSECS mail
In message <002d01cf14bc$12a03490$37e09db0$@comcast.net>, "Gerard Ashton" write
s:
>The time of birth
>would be the actual time of birth, but the time zone (and hence date) would
>be that of the location of the conveyance at the time of birth, or the time
>zone where the child is removed from the
On 2014-01-18 11:39 PM, Clive D.W. Feather wrote:
Brooks Harris said:
tm_sec + tm_min*60 + tm_hour*3600 + tm_yday*86400 +
(tm_year???70)*31536000 + ((tm_year???69)/4)*86400 ???
((tm_year???1)/100)*86400 + ((tm_year+299)/400)*86400
This is an *uncompensated-for-leap-seconds* Gregorian calendar c
On 18 Jan 2014 at 19:51, Warner Losh wrote:
> Of course, the 6 month window does make it impossible to compute a time_t for
> a known
> interval into the future that's longer than 6 months away...
What are the applications that actually need to schedule events more
than 6 months in the future t
On Sun 2014-01-19T07:39:51 +, Clive D.W. Feather hath writ:
> When I was on the ISO C (*NOT* "ANSI c") committee, we looked at the issue.
> Then we asked the expert community (that is, you lot), to come up with a
> consensus proposal that we could look at. As far as I know, the committee
> is s
Date/time manipulation software sometimes converts a date expressed as day,
month, year, time to a number, as in Excel. If the number counts leap
seconds, and an event is more than 6 months in the future, it will be
necessary to search for the number using a range rather than an exact
number. For e
On Jan 18, 2014, at 10:16 PM, Tom Van Baak wrote:
>> The problem is that all applications should care about leap seconds.
>> It is a part of the time standard (UTC) that is papered over in POSIX time_t.
>> This is a false partitioning, and what causes the probelms.
>
> Warner,
>
> "All" applica
On Jan 18, 2014, at 11:03 PM, Brooks Harris wrote:
> On 2014-01-18 08:53 AM, Warner Losh wrote:
>> On Jan 18, 2014, at 6:31 AM, Magnus Danielson wrote:
>>
>>> On 18/01/14 11:56, Poul-Henning Kamp wrote:
In message <52da2a0f.9060...@rubidium.dyndns.org>, Magnus Danielson writes:
>
On Jan 19, 2014, at 8:34 AM, Daniel R. Tobias wrote:
> On 18 Jan 2014 at 19:51, Warner Losh wrote:
>
>> Of course, the 6 month window does make it impossible to compute a time_t
>> for a known
>> interval into the future that's longer than 6 months away...
>
> What are the applications that ac
On Sun 2014-01-19T09:20:31 -0700, Warner Losh hath writ:
> That's what I mean by "all" applications (computer applications)
> should care. Otherwise we get the two-tier system we have now where
> leap seconds are such second class citizens applications wanting to
> get them right have to jump thro
In message <20140119164807.ga19...@ucolick.org>, Steve Allen writes:
>If the leap seconds were placed into a similarly inconsequential part
>of the interfaces then the applications could be similarly wrong about
>leap seconds yet life would go on.
They are. It does. So far.
--
Poul-Henning K
On Jan 19, 2014, at 9:48 AM, Steve Allen wrote:
> On Sun 2014-01-19T09:20:31 -0700, Warner Losh hath writ:
>> That's what I mean by "all" applications (computer applications)
>> should care. Otherwise we get the two-tier system we have now where
>> leap seconds are such second class citizens app
Daniel R. Tobias wrote on Sun, 19 Jan 2014
at 10:34:41 -0500 in <52dbf091.26529.1101b...@dan.tobias.name>:
> What are the applications that actually need to schedule events more
> than 6 months in the future that need to be precisely synchronized to
> civil time at a resolution of under a seco
On 19 January 2014 15:34, Daniel R. Tobias wrote:
> On 18 Jan 2014 at 19:51, Warner Losh wrote:
>
>> Of course, the 6 month window does make it impossible to compute a time_t
>> for a known
>> interval into the future that's longer than 6 months away...
>
> What are the applications that actually
On Jan 19, 2014, at 11:21 AM, Stephen Colebourne wrote:
> On 19 January 2014 15:34, Daniel R. Tobias wrote:
>> On 18 Jan 2014 at 19:51, Warner Losh wrote:
>>
>>> Of course, the 6 month window does make it impossible to compute a time_t
>>> for a known
>>> interval into the future that's longer
On 19 Jan 2014 at 11:07, Gerard Ashton wrote:
> Date/time manipulation software sometimes converts a date expressed as day,
> month, year, time to a number, as in Excel. If the number counts leap
> seconds, and an event is more than 6 months in the future, it will be
> necessary to search for the
On 2014-01-19 08:07 AM, Gerard Ashton wrote:
Date/time manipulation software sometimes converts a date expressed as day,
month, year, time to a number, as in Excel. If the number counts leap
seconds, and an event is more than 6 months in the future, it will be
necessary to search for the number u
On Sat, 18 Jan 2014 19:51:33 -0700, Warner Losh wrote:
>
> On Jan 18, 2014, at 5:21 PM, Steffen (Daode) Nurpmeso wrote:
>>
>> Those applications which do care about leap seconds can determine
>> how to handle them in whatever way those applications feel is
>> best.
>
> The problem is that all
In message <52dc19ff.9499.11a39...@dan.tobias.name>, "Daniel R. Tobias" writes:
>When I'm making an advance dinner reservation for 7 PM on October 1,
>2014 in New York City, I expect that [...]
That used to be the "sensible party position", but it breaks down
in heaps once you start to schedule
On Sat, 18 Jan 2014 23:10:41 -0800, Brooks Harris wrote:
> On 2014-01-18 09:39 AM, Zefram wrote:
>> Joseph Gwinn wrote:
>>> No. If your poke around into how time is used, you will discover that
>>> what is stored is the count of seconds since the Epoch. Broken-down
>>> time is used only when ther
On 19 Jan 2014, at 09:58, Poul-Henning Kamp wrote:
> In message <002d01cf14bc$12a03490$37e09db0$@comcast.net>, "Gerard Ashton"
> write
> s:
>
>> The time of birth
>> would be the actual time of birth, but the time zone (and hence date) would
>> be that of the location of the conveyance at the
In message <7c853a0f-1460-4eb0-b8ce-b5ca5c06e...@batten.eu.org>, Ian Batten wri
tes:
>But your recorded date of birth can have quite noticeable effects
>at the one-day level.In England,
>the August 31st/September 1st boundary has marked effects on
>educational outcomes all the way
>through the
John Hawkinson wrote:
> Suppose a user enters an event in my calendar for 3:00pm US/Eastern on
> August 1, 2014.
>
> Then a leap second happens.
>
> If my calendar software changes my event to start at 2:59:59pm
Scenarios like the above are precisely the reason why I, Markus Kuhn
and Google Lea
I've renamed and reorganized the proposed "timescales" of CCT to reflect
the responses I've gotten and to hopefully make the intentions clear. I
had used the terms "proleptic UTC" and "proleptic TAI" and these are now
renamed.
There are other important elements the CCT proposal, including coun
> The olson database updates will take care of that.
One of the problems with leap-seconds is that they aren't predictable and the
software in embedded gear doesn't get updated. That also means the time zone
data doesn't get updated.
What sort of embedded gear uses time but not time zones? Or
On 2014-01-19 08:26 AM, Warner Losh wrote:
On Jan 18, 2014, at 11:03 PM, Brooks Harris wrote:
On 2014-01-18 08:53 AM, Warner Losh wrote:
On Jan 18, 2014, at 6:31 AM, Magnus Danielson wrote:
On 18/01/14 11:56, Poul-Henning Kamp wrote:
In message <52da2a0f.9060...@rubidium.dyndns.org>, Magnus
On Jan 19, 2014, at 2:12 PM, Hal Murray wrote:
>> The olson database updates will take care of that.
>
> One of the problems with leap-seconds is that they aren't predictable and the
> software in embedded gear doesn't get updated. That also means the time zone
> data doesn't get updated.
>
On Jan 19, 2014, at 1:58 PM, Michael Spacefalcon wrote:
> John Hawkinson wrote:
>
>> Suppose a user enters an event in my calendar for 3:00pm US/Eastern on
>> August 1, 2014.
>>
>> Then a leap second happens.
>>
>> If my calendar software changes my event to start at 2:59:59pm
>
> Scenarios
On Sun, 19 Jan 2014 13:14:33 -0800, Brooks Harris wrote:
> On 2014-01-19 08:26 AM, Warner Losh wrote:
>> On Jan 18, 2014, at 11:03 PM, Brooks Harris wrote:
>>
>>> On 2014-01-18 08:53 AM, Warner Losh wrote:
On Jan 18, 2014, at 6:31 AM, Magnus Danielson wrote:
> On 18/01/14 11:56, Pou
On Sun, 19 Jan 2014 16:02:54 -0700, Warner Losh wrote:
>
> On Jan 19, 2014, at 2:12 PM, Hal Murray wrote:
>
>>> The olson database updates will take care of that.
>>
>> One of the problems with leap-seconds is that they aren't
>> predictable and the
>> software in embedded gear doesn't get upd
In message <20140119182454462945.77293...@comcast.net>, Joseph Gwinn writes:
>This is the bounding case. ATC systems typically do not jump at the
>leap, they slide over 10 seconds or so.
In Denmark they go hands off "until stuff look normal again".
--
Poul-Henning Kamp | UNIX since Zilo
On Sun, 19 Jan 2014 23:31:00 +, Poul-Henning Kamp wrote:
> In message <20140119182454462945.77293...@comcast.net>, Joseph Gwinn writes:
>
>> This is the bounding case. ATC systems typically do not jump at the
>> leap, they slide over 10 seconds or so.
>
> In Denmark they go hands off "until
On 2014-01-19 11:06 AM, Joseph Gwinn wrote:
NTP *does* refer to POSIX - Figure 4: Interesting Historic NTP Dates
refers to "First day UNIX" and locates it 63072000 seconds before
1972-01-01T00:00:00Z (UTC). This helps solve one problem - when,
exactly, was the POSIX "the Epoch".
Ok. I meant a no
Brooks Harris wrote:
>The main objective of the CCT design is to recast TAI and UTC into a
>more unified specification appropriate for time-keeping from 1972
>onward.
Just so we're clear about scope, your message doesn't actually respecify
TAI and UTC. You've defined your PAT and CCT, for the pos
On Sun, 19 Jan 2014, Steve Allen wrote:
> On Sun 2014-01-19T07:39:51 +, Clive D.W. Feather hath writ:
> > When I was on the ISO C (*NOT* "ANSI c") committee, we looked at the issue.
> > Then we asked the expert community (that is, you lot), to come up with a
> > consensus proposal that we coul
On Jan 19, 2014, at 12:31 AM, Clive D.W. Feather wrote:
> Rob Seaman said:
>> Systems, software and civilization depend on both interval time and Earth
>> orientation time.
>
> In what way does civilization depend on Earth orientation time?
Thanks for acknowledging (through omission) the many
On Mon, 20 Jan 2014 00:16:13 + (UTC), Joseph S. Myers wrote:
> On Sun, 19 Jan 2014, Steve Allen wrote:
>
>> On Sun 2014-01-19T07:39:51 +, Clive D.W. Feather hath writ:
>>> When I was on the ISO C (*NOT* "ANSI c") committee, we looked at
>>> the issue.
>>> Then we asked the expert communit
Warner Losh wrote:
> Second, you are breaking one of the aspects of time
Wrong - I simply assert other people's right to define the word "time"
in a different way than you do. There exist perfectly valid definitions
of the word "time" which are distinct from "interval time", and which
are not b
On Sun 2014-01-19T23:53:44 +, Zefram hath writ:
> I'm not familiar with PTP, but I see a number of documents saying that it
> uses an epoch of 1970-01-01 00:00:00 TAI. If so, unlike the NTP origin
> this is a perfectly well-defined real instant.
Yes, well-defined, but not defined in a contemp
On 2014-01-19 03:53 PM, Zefram wrote:
Your definitions are generally poor. There is much that you omit or
make horrendously unclear.
There really aren't any definitions yet. Its an informal email. I'd
hoped I could make a little progress without completing the entire
document. Maybe not.
> All the embedded gear I've done runs on UTC. But it also has requirements
> for 'cold start' that are incompatible with GPS and couldn't be met if the
> system had been off across a leap second. It didn't deal with localtime, so
> DST insanity didn't matter so much...
I can't quite figure out
On Jan 19, 2014, at 9:00 PM, Hal Murray wrote:
>
>> All the embedded gear I've done runs on UTC. But it also has requirements
>> for 'cold start' that are incompatible with GPS and couldn't be met if the
>> system had been off across a leap second. It didn't deal with localtime, so
>> DST insan
Warner Losh wrote:
> Also, these systems were not on the internet, so downloading one of the many
> sources of TAI-UTC differences wasn't an option.
OK, obviously asking every system to be connected to the Internet
would be a non-starter, for security etc reasons, but what's wrong
with dedicated
On Jan 19, 2014, at 10:15 PM, Michael Spacefalcon wrote:
> Warner Losh wrote:
>
>> Also, these systems were not on the internet, so downloading one of the many
>> sources of TAI-UTC differences wasn't an option.
>
> OK, obviously asking every system to be connected to the Internet
> would be a
44 matches
Mail list logo
