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
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
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
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 still
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
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 applications
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 actually
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 through
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 Kamp
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
Daniel R. Tobias d...@tobias.name 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
On 19 January 2014 15:34, Daniel R. Tobias d...@tobias.name 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
On Jan 19, 2014, at 11:21 AM, Stephen Colebourne wrote:
On 19 January 2014 15:34, Daniel R. Tobias d...@tobias.name 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
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
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 there is a
On 19 Jan 2014, at 09:58, Poul-Henning Kamp p...@phk.freebsd.dk 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
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 jh...@mit.edu 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
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 counting
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.
What
On Jan 19, 2014, at 1:58 PM, Michael Spacefalcon wrote:
John Hawkinson jh...@mit.edu 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, Poul-Henning Kamp
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 updated. That
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 Zilog
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 stuff
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
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
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 could look
On Jan 19, 2014, at 12:31 AM, Clive D.W. Feather cl...@davros.org 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)
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 community (that is,
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
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 insanity
Warner Losh i...@bsdimp.com 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
On Jan 19, 2014, at 10:15 PM, Michael Spacefalcon wrote:
Warner Losh i...@bsdimp.com 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
41 matches
Mail list logo
