Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.os.linux.misc > #13769 > unrolled thread
| Started by | not.socialnetwork@gmail.com |
|---|---|
| First post | 2015-02-28 12:13 +0000 |
| Last post | 2015-04-14 06:46 +0000 |
| Articles | 20 on this page of 219 — 49 participants |
Back to article view | Back to comp.os.linux.misc
Keeping 'order' without RTC. not.socialnetwork@gmail.com - 2015-02-28 12:13 +0000
Re: Keeping 'order' without RTC. Robert Heller <heller@deepsoft.com> - 2015-02-28 06:52 -0600
Re: Keeping 'order' without RTC. Rob <nomail@example.com> - 2015-02-28 13:17 +0000
Re: Keeping 'order' without RTC. Robert Heller <heller@deepsoft.com> - 2015-02-28 07:59 -0600
Re: Keeping 'order' without RTC. William Unruh <unruh@invalid.ca> - 2015-02-28 18:28 +0000
Re: Keeping 'order' without RTC. Rob <nomail@example.com> - 2015-02-28 19:13 +0000
Re: Keeping 'order' without RTC. William Unruh <unruh@invalid.ca> - 2015-02-28 19:22 +0000
Re: Keeping 'order' without RTC. Baho Utot <baho-utot@columbus.rr.com> - 2015-02-28 15:48 -0500
Re: Keeping 'order' without RTC. Rob <nomail@example.com> - 2015-02-28 21:14 +0000
Re: Keeping 'order' without RTC. mm0fmf <none@mailinator.com> - 2015-02-28 22:40 +0000
Re: Keeping 'order' without RTC. John Hasler <jhasler@newsguy.com> - 2015-02-28 18:01 -0600
Re: Keeping 'order' without RTC. William Unruh <unruh@invalid.ca> - 2015-03-01 01:44 +0000
Re: Keeping 'order' without RTC. Rob <nomail@example.com> - 2015-03-01 07:21 +0000
Re: Keeping 'order' without RTC. cl@isbd.net - 2015-03-01 09:17 +0000
Re: Keeping 'order' without RTC. alister <alister.nospam.ware@ntlworld.com> - 2015-03-01 10:08 +0000
Re: Keeping 'order' without RTC. Martin Gregorie <martin@address-in-sig.invalid> - 2015-03-01 11:29 +0000
Re: Keeping 'order' without RTC. William Unruh <unruh@invalid.ca> - 2015-03-01 17:18 +0000
Re: Keeping 'order' without RTC. Martin Gregorie <martin@address-in-sig.invalid> - 2015-03-01 18:33 +0000
Re: Keeping 'order' without RTC. Unknown <dog@gmail.com> - 2015-03-02 09:06 +0000
Re: Keeping 'order' without RTC. alister <alister.nospam.ware@ntlworld.com> - 2015-03-02 09:19 +0000
Re: Keeping 'order' without RTC. mm0fmf <none@mailinator.com> - 2015-03-02 17:13 +0000
Re: Keeping 'order' without RTC. Rob <nomail@example.com> - 2015-03-02 09:29 +0000
Re: Keeping 'order' without RTC. William Unruh <unruh@invalid.ca> - 2015-03-02 16:27 +0000
Re: Keeping 'order' without RTC. Jim Diamond <Jim.Diamond@deletethis.AcadiaU.ca> - 2015-03-05 08:36 -0400
Re: Keeping 'order' without RTC. cl@isbd.net - 2015-03-01 11:25 +0000
Re: Keeping 'order' without RTC. Rob <nomail@example.com> - 2015-03-01 11:40 +0000
Re: Keeping 'order' without RTC. alister <alister.nospam.ware@ntlworld.com> - 2015-03-01 16:08 +0000
Re: Keeping 'order' without RTC. Rich <rich@example.invalid> - 2015-03-01 17:11 +0000
Re: Keeping 'order' without RTC. Martin Gregorie <martin@address-in-sig.invalid> - 2015-03-01 18:47 +0000
Re: Keeping 'order' without RTC. David Taylor <david-taylor@blueyonder.co.uk.invalid> - 2015-03-01 19:26 +0000
Re: Keeping 'order' without RTC. J G Miller <miller@yoyo.ORG> - 2015-03-03 22:27 +0000
Re: Keeping 'order' without RTC. Martin Gregorie <martin@address-in-sig.invalid> - 2015-03-04 00:50 +0000
Re: Keeping 'order' without RTC. William Unruh <unruh@invalid.ca> - 2015-03-04 01:51 +0000
Re: Keeping 'order' without RTC. J G Miller <miller@yoyo.ORG> - 2015-03-04 17:05 +0000
Re: Keeping 'order' without RTC. William Unruh <unruh@invalid.ca> - 2015-03-04 17:59 +0000
Re: Keeping 'order' without RTC. David Taylor <david-taylor@blueyonder.co.uk.invalid> - 2015-03-05 11:46 +0000
Re: Keeping 'order' without RTC. William Unruh <unruh@invalid.ca> - 2015-03-06 00:00 +0000
Re: Keeping 'order' without RTC. David Taylor <david-taylor@blueyonder.co.uk.invalid> - 2015-03-06 06:55 +0000
Re: Keeping 'order' without RTC. Tim Watts <tw_usenet@dionic.net> - 2015-03-04 07:31 +0000
Re: Keeping 'order' without RTC. Martin Gregorie <martin@address-in-sig.invalid> - 2015-03-04 10:00 +0000
Re: Keeping 'order' without RTC. Tim Watts <tw_usenet@dionic.net> - 2015-03-04 11:01 +0000
Re: Keeping 'order' without RTC. Martin Gregorie <martin@address-in-sig.invalid> - 2015-03-04 22:15 +0000
Re: Keeping 'order' without RTC. Tim Watts <tw_usenet@dionic.net> - 2015-03-04 22:20 +0000
Re: Keeping 'order' without RTC. William Unruh <unruh@invalid.ca> - 2015-03-05 01:07 +0000
Re: Keeping 'order' without RTC. Martin Gregorie <martin@address-in-sig.invalid> - 2015-03-05 10:20 +0000
Re: Keeping 'order' without RTC. Rob <nomail@example.com> - 2015-03-05 10:51 +0000
Re: Keeping 'order' without RTC. David Taylor <david-taylor@blueyonder.co.uk.invalid> - 2015-03-05 11:53 +0000
Re: Keeping 'order' without RTC. Rob <nomail@example.com> - 2015-03-05 15:35 +0000
Re: Keeping 'order' without RTC. David Taylor <david-taylor@blueyonder.co.uk.invalid> - 2015-03-05 17:24 +0000
Re: Keeping 'order' without RTC. David Taylor <david-taylor@blueyonder.co.uk.invalid> - 2015-03-05 11:49 +0000
Re: Keeping 'order' without RTC. William Unruh <unruh@invalid.ca> - 2015-03-05 23:56 +0000
Re: Keeping 'order' without RTC. William Unruh <unruh@invalid.ca> - 2015-03-04 16:06 +0000
Re: Keeping 'order' without RTC. Martin Gregorie <martin@address-in-sig.invalid> - 2015-03-04 22:34 +0000
Re: Keeping 'order' without RTC. Rob <nomail@example.com> - 2015-03-04 08:23 +0000
Re: Keeping 'order' without RTC. Rich <rich@example.invalid> - 2015-03-04 11:19 +0000
Re: Keeping 'order' without RTC. mm0fmf <none@mailinator.com> - 2015-03-04 17:44 +0000
Re: Keeping 'order' without RTC. William Unruh <unruh@invalid.ca> - 2015-03-04 16:10 +0000
Re: Keeping 'order' without RTC. Tauno Voipio <tauno.voipio@notused.fi.invalid> - 2015-03-04 10:43 +0200
Re: Keeping 'order' without RTC. David Taylor <david-taylor@blueyonder.co.uk.invalid> - 2015-03-04 09:28 +0000
Re: Keeping 'order' without RTC. William Unruh <unruh@invalid.ca> - 2015-03-04 16:11 +0000
Re: Keeping 'order' without RTC. Rob <nomail@example.com> - 2015-03-04 08:22 +0000
Re: Keeping 'order' without RTC. Richard Kettlewell <rjk@greenend.org.uk> - 2015-02-28 13:34 +0000
Re: Keeping 'order' without RTC. Baho Utot <baho-utot@columbus.rr.com> - 2015-02-28 09:14 -0500
Re: Keeping 'order' without RTC. Robert Heller <heller@deepsoft.com> - 2015-02-28 08:52 -0600
Re: Keeping 'order' without RTC. Richard Kettlewell <rjk@greenend.org.uk> - 2015-02-28 15:22 +0000
Re: Keeping 'order' without RTC. Baho Utot <baho-utot@columbus.rr.com> - 2015-02-28 15:46 -0500
Re: Keeping 'order' without RTC. Richard Kettlewell <rjk@greenend.org.uk> - 2015-02-28 21:10 +0000
Re: Keeping 'order' without RTC. Baho Utot <baho-utot@columbus.rr.com> - 2015-02-28 19:48 -0500
Re: Keeping 'order' without RTC. Richard Kettlewell <rjk@greenend.org.uk> - 2015-03-01 09:08 +0000
Re: Keeping 'order' without RTC. Baho Utot <baho-utot@columbus.rr.com> - 2015-03-01 07:52 -0500
Re: Keeping 'order' without RTC. Rob Morley <nospam@ntlworld.com> - 2015-03-01 16:15 +0000
Re: Keeping 'order' without RTC. Mike Fleming <{mike}@tauzero.co.uk> - 2015-03-01 20:28 +0000
Re: Keeping 'order' without RTC. not.socialnetwork@gmail.com - 2015-03-01 11:00 +0000
Re: Keeping 'order' without RTC. Rob <nomail@example.com> - 2015-03-01 11:17 +0000
Re: Keeping 'order' without RTC. Unknown <dog@gmail.com> - 2015-03-03 07:37 +0000
Re: Keeping 'order' without RTC. William Unruh <unruh@invalid.ca> - 2015-03-03 17:21 +0000
Re: Keeping 'order' without RTC. Martin Gregorie <martin@address-in-sig.invalid> - 2015-03-01 11:43 +0000
Re: Keeping 'order' without RTC. RRansil <ransil@invalid.invalid> - 2015-03-01 10:44 -0800
Re: Keeping 'order' without RTC. mm0fmf <none@mailinator.com> - 2015-03-01 19:08 +0000
Re: Keeping 'order' without RTC. Martin Gregorie <martin@address-in-sig.invalid> - 2015-03-01 20:46 +0000
Re: Keeping 'order' without RTC. RRansil <ransil@invalid.invalid> - 2015-03-01 13:12 -0800
Re: Keeping 'order' without RTC. RRansil <ransil@invalid.invalid> - 2015-03-01 13:07 -0800
Re: Keeping 'order' without RTC. William Unruh <unruh@invalid.ca> - 2015-03-01 21:56 +0000
Re: Keeping 'order' without RTC. RRansil <ransil@invalid.invalid> - 2015-03-01 14:49 -0800
Re: Keeping 'order' without RTC. William Unruh <unruh@invalid.ca> - 2015-02-28 18:26 +0000
Re: Keeping 'order' without RTC. David Taylor <david-taylor@blueyonder.co.uk.invalid> - 2015-02-28 19:29 +0000
Re: Keeping 'order' without RTC. Michael Black <et472@ncf.ca> - 2015-03-01 14:22 -0500
Re: Keeping 'order' without RTC. William Unruh <unruh@invalid.ca> - 2015-03-01 21:54 +0000
Re: Keeping 'order' without RTC. Johny B Good <johnny-b-good@invalid.ntlworld.com> - 2015-03-02 16:12 +0000
Re: Keeping 'order' without RTC. Nomen Nescio <nobody@dizum.com> - 2015-03-02 19:57 +0100
Re: Keeping 'order' without RTC. "David B" <askforemail@gmail.com> - 2015-03-03 10:15 +0000
Re: Keeping 'order' without RTC. Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2015-03-03 19:38 +0000
Re: Keeping 'order' without RTC. Jack Strangio <jackstrangio@yahoo.com> - 2015-03-04 10:43 +0000
Re: Keeping 'order' without RTC. Tim Watts <tw_usenet@dionic.net> - 2015-03-04 11:23 +0000
Re: Keeping 'order' without RTC. The Natural Philosopher <tnp@invalid.invalid> - 2015-03-04 11:30 +0000
Re: Keeping 'order' without RTC. Johny B Good <johnny-b-good@invalid.ntlworld.com> - 2015-03-04 15:25 +0000
Re: Keeping 'order' without RTC. William Unruh <unruh@invalid.ca> - 2015-03-04 16:13 +0000
Re: Keeping 'order' without RTC. The Natural Philosopher <tnp@invalid.invalid> - 2015-03-04 16:31 +0000
Re: Keeping 'order' without RTC. "David B" <askforemail@gmail.com> - 2015-03-04 16:38 +0000
Re: Keeping 'order' without RTC. Aragorn <thorongil@telenet.be.invalid> - 2015-03-04 17:39 +0100
Re: Keeping 'order' without RTC. "David B" <askforemail@gmail.com> - 2015-03-04 16:53 +0000
Re: Keeping 'order' without RTC. The Natural Philosopher <tnp@invalid.invalid> - 2015-03-04 17:03 +0000
Re: Keeping 'order' without RTC. Bobbie Sellers <bliss-sf4ever@dslextreme.com> - 2015-03-04 08:52 -0800
Re: Keeping 'order' without RTC. Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2015-03-05 20:23 -0500
Re: Keeping 'order' without RTC. Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2015-03-04 17:29 +0000
Re: Keeping 'order' without RTC. Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2015-03-05 20:16 -0500
Re: Keeping 'order' without RTC. Michael Black <et472@ncf.ca> - 2015-03-05 22:38 -0500
Re: Keeping 'order' without RTC. Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2015-03-06 17:46 +0000
Re: Keeping 'order' without RTC. Gordon Henderson <gordon+usenet@drogon.net> - 2015-03-06 18:45 +0000
Re: Keeping 'order' without RTC. Michael J. Mahon <mjmahon@aol.com> - 2015-03-06 14:56 -0600
Re: Keeping 'order' without RTC. Jack Strangio <jackstrangio@yahoo.com> - 2015-03-06 06:30 +0000
Re: Keeping 'order' without RTC. "Kerr Mudd-John" <admin@127.0.0.1> - 2015-03-06 08:24 +0000
Re: Keeping 'order' without RTC. Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2015-03-06 17:46 +0000
Re: Keeping 'order' without RTC. Bobbie Sellers <bliss-sf4ever@dslextreme.com> - 2015-03-06 10:02 -0800
Re: Keeping 'order' without RTC. Rob <nomail@example.com> - 2015-03-06 09:26 +0000
Re: Keeping 'order' without RTC. Jack Strangio <jackstrangio@yahoo.com> - 2015-03-07 00:34 +0000
Re: Keeping 'order' without RTC. Jack Strangio <jackstrangio@yahoo.com> - 2015-03-06 06:21 +0000
Re: Keeping 'order' without RTC. alister <alister.nospam.ware@ntlworld.com> - 2015-03-06 11:17 +0000
Re: Keeping 'order' without RTC. Michael J. Mahon <mjmahon@aol.com> - 2015-03-06 14:56 -0600
Re: Keeping 'order' without RTC. Rob <nomail@example.com> - 2015-03-07 12:14 +0000
Re: Keeping 'order' without RTC. Jack Strangio <jackstrangio@yahoo.com> - 2015-03-08 02:38 +0000
Re: Keeping 'order' without RTC. Michael J. Mahon <mjmahon@aol.com> - 2015-03-07 21:15 -0600
Re: Keeping 'order' without RTC. John Hasler <jhasler@newsguy.com> - 2015-03-07 21:44 -0600
Re: Keeping 'order' without RTC. Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2015-03-08 16:26 +0000
Re: Keeping 'order' without RTC. Rob <nomail@example.com> - 2015-03-08 09:42 +0000
Re: Keeping 'order' without RTC. Johny B Good <johnny-b-good@invalid.ntlworld.com> - 2015-03-03 23:20 +0000
Re: Keeping 'order' without RTC. Unknown <dog@gmail.com> - 2015-03-05 08:52 +0000
Re: Keeping 'order' without RTC. alister <alister.nospam.ware@ntlworld.com> - 2015-03-05 09:13 +0000
Re: Keeping 'order' without RTC. Rich <rich@example.invalid> - 2015-03-05 09:47 +0000
Re: Keeping 'order' without RTC. Johny B Good <johnny-b-good@invalid.ntlworld.com> - 2015-03-06 01:31 +0000
Re: Keeping 'order' without RTC. Unknown <dog@gmail.com> - 2015-03-11 04:53 +0000
Re: Keeping 'order' without RTC. William Unruh <unruh@invalid.ca> - 2015-03-11 05:24 +0000
Re: Keeping 'order' without RTC. Keith Keller <kkeller-usenet@wombat.san-francisco.ca.us> - 2015-03-11 07:58 -0700
Re: Keeping 'order' without RTC. mm0fmf <none@mailinator.com> - 2015-03-11 19:01 +0000
Re: Keeping 'order' without RTC. Joe Beanfish <joebeanfish@nospam.duh> - 2015-03-11 13:20 +0000
Re: Keeping 'order' without RTC. Unknown <dog@gmail.com> - 2015-04-12 17:17 +0000
Re: Keeping 'order' without RTC. Michael Black <et472@ncf.ca> - 2015-04-12 13:50 -0400
Re: Keeping 'order' without RTC. Joe Beanfish <joebeanfish@nospam.duh> - 2015-04-13 13:14 +0000
Re: Keeping 'order' without RTC. The Natural Philosopher <tnp@invalid.invalid> - 2015-04-13 15:10 +0100
Re: Keeping 'order' without RTC. Gordon Levi <gordon@address.invalid> - 2015-04-14 00:30 +1000
Re: Keeping 'order' without RTC. The Natural Philosopher <tnp@invalid.invalid> - 2015-04-13 17:47 +0100
Re: Keeping 'order' without RTC. Morten Reistad <first@last.name> - 2015-04-15 22:37 +0200
Re: Keeping 'order' without RTC. Rob Morley <nospam@ntlworld.com> - 2015-04-17 02:32 +0100
Re: Keeping 'order' without RTC. Unknown <dog@gmail.com> - 2015-04-25 23:09 +0000
Re: Keeping 'order' without RTC. Joe Beanfish <joebeanfish@nospam.duh> - 2015-04-27 13:13 +0000
Re: Keeping 'order' without RTC. Michael Black <et472@ncf.ca> - 2015-04-13 16:22 -0400
Re: Keeping 'order' without RTC. Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2015-04-13 21:14 -0400
Re: Keeping 'order' without RTC. Dan Espen <despen@verizon.net> - 2015-04-13 21:55 -0400
Re: Keeping 'order' without RTC. Martin Gregorie <martin@address-in-sig.invalid> - 2015-04-14 09:06 +0000
Re: Keeping 'order' without RTC. The Natural Philosopher <tnp@invalid.invalid> - 2015-04-14 10:12 +0100
Re: Keeping 'order' without RTC. David Taylor <david-taylor@blueyonder.co.uk.invalid> - 2015-04-14 10:29 +0100
Re: Keeping 'order' without RTC. Martin Gregorie <martin@address-in-sig.invalid> - 2015-04-14 12:05 +0000
Re: Keeping 'order' without RTC. Jerry Peters <jerry@example.invalid> - 2015-04-14 22:08 +0000
Re: Keeping 'order' without RTC. Michael Black <et472@ncf.ca> - 2015-04-16 14:11 -0400
Re: Keeping 'order' without RTC. Martin Gregorie <martin@address-in-sig.invalid> - 2015-04-16 20:15 +0000
Re: Keeping 'order' without RTC. c28f62@TheWorld.com (Mark Kramer) - 2015-04-14 05:25 +0000
Re: Keeping 'order' without RTC. Michael Black <et472@ncf.ca> - 2015-04-16 14:13 -0400
Re: Keeping 'order' without RTC. Jerry Peters <jerry@example.invalid> - 2015-04-16 20:18 +0000
Re: Keeping 'order' without RTC. c28f62@TheWorld.com (Mark Kramer) - 2015-05-04 03:44 +0000
Re: Keeping 'order' without RTC. William Unruh <unruh@invalid.ca> - 2015-05-04 04:44 +0000
Re: Keeping 'order' without RTC. Jack Ryan <noreply@remailer.cpunk.us> - 2015-05-04 07:54 -0400
Re: Keeping 'order' without RTC. William Unruh <unruh@invalid.ca> - 2015-05-04 18:26 +0000
Re: Keeping 'order' without RTC. "John Williams (News)" <UCEbin@tiscali.co.uk> - 2015-05-04 19:40 +0100
Re: Keeping 'order' without RTC. Kees Theunissen <theuniss@rijnh.nl> - 2015-05-04 22:31 +0200
Re: Keeping 'order' without RTC. William Unruh <unruh@invalid.ca> - 2015-05-04 22:35 +0000
Re: Keeping 'order' without RTC. John Hasler <jhasler@newsguy.com> - 2015-05-04 19:13 -0500
Re: Keeping 'order' without RTC. William Unruh <unruh@invalid.ca> - 2015-05-05 02:56 +0000
Re: Keeping 'order' without RTC. Michael Baeuerle <michael.baeuerle@stz-e.de> - 2015-05-05 08:04 +0000
Re: Keeping 'order' without RTC. Richard Kettlewell <rjk@greenend.org.uk> - 2015-05-05 09:22 +0100
Re: Keeping 'order' without RTC. John Hasler <jhasler@newsguy.com> - 2015-05-05 08:26 -0500
Re: Keeping 'order' without RTC. William Unruh <unruh@invalid.ca> - 2015-05-05 18:08 +0000
Re: Keeping 'order' without RTC. druck <news@druck.org.uk> - 2015-05-11 23:16 +0100
Re: Keeping 'order' without RTC. John Hasler <jhasler@newsguy.com> - 2015-05-11 17:52 -0500
Re: Keeping 'order' without RTC. The Natural Philosopher <tnp@invalid.invalid> - 2015-05-12 07:09 +0100
Re: Keeping 'order' without RTC. William Unruh <unruh@invalid.ca> - 2015-05-12 06:47 +0000
Re: Keeping 'order' without RTC. The Natural Philosopher <tnp@invalid.invalid> - 2015-05-12 08:27 +0100
Re: Keeping 'order' without RTC. William Unruh <unruh@invalid.ca> - 2015-05-12 15:44 +0000
Re: Keeping 'order' without RTC. Richard Kettlewell <rjk@greenend.org.uk> - 2015-05-12 17:08 +0100
Re: Keeping 'order' without RTC. William Unruh <unruh@invalid.ca> - 2015-05-12 17:21 +0000
Re: Keeping 'order' without RTC. John Hasler <jhasler@newsguy.com> - 2015-05-12 12:41 -0500
Re: Keeping 'order' without RTC. Richard Kettlewell <rjk@greenend.org.uk> - 2015-05-12 19:03 +0100
Re: Keeping 'order' without RTC. William Unruh <unruh@invalid.ca> - 2015-05-12 18:26 +0000
Re: Keeping 'order' without RTC. Richard Kettlewell <rjk@greenend.org.uk> - 2015-05-12 19:59 +0100
Re: Keeping 'order' without RTC. William Unruh <unruh@invalid.ca> - 2015-05-12 20:05 +0000
Re: Keeping 'order' without RTC. Richard Kettlewell <rjk@greenend.org.uk> - 2015-05-12 22:58 +0100
Re: Keeping 'order' without RTC. William Unruh <unruh@invalid.ca> - 2015-05-13 01:15 +0000
Re: Keeping 'order' without RTC. The Natural Philosopher <tnp@invalid.invalid> - 2015-05-13 08:14 +0100
Re: Keeping 'order' without RTC. Richard Kettlewell <rjk@greenend.org.uk> - 2015-05-13 09:24 +0100
Re: Keeping 'order' without RTC. John Hasler <jhasler@newsguy.com> - 2015-05-12 11:50 -0500
Re: Keeping 'order' without RTC. The Natural Philosopher <tnp@invalid.invalid> - 2015-05-12 18:52 +0100
Re: Keeping 'order' without RTC. c28f62@TheWorld.com (Mark Kramer) - 2015-05-12 17:29 +0000
Re: Keeping 'order' without RTC. William Unruh <unruh@invalid.ca> - 2015-05-12 18:36 +0000
Re: Keeping 'order' without RTC. Richard Kettlewell <rjk@greenend.org.uk> - 2015-05-12 20:00 +0100
Re: Keeping 'order' without RTC. William Unruh <unruh@invalid.ca> - 2015-05-12 20:06 +0000
Re: Keeping 'order' without RTC. c28f62@TheWorld.com (Mark Kramer) - 2015-05-12 06:14 +0000
Re: Keeping 'order' without RTC. c28f62@TheWorld.com (Mark Kramer) - 2015-05-12 06:09 +0000
Re: Keeping 'order' without RTC. William Unruh <unruh@invalid.ca> - 2015-05-12 06:44 +0000
Re: Keeping 'order' without RTC. c28f62@TheWorld.com (Mark Kramer) - 2015-05-12 17:45 +0000
Re: Keeping 'order' without RTC. The Natural Philosopher <tnp@invalid.invalid> - 2015-05-12 21:06 +0100
Re: Keeping 'order' without RTC. William Unruh <unruh@invalid.ca> - 2015-04-14 23:18 +0000
Re: Keeping 'order' without RTC. Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2015-04-14 20:58 -0400
Re: Keeping 'order' without RTC. William Unruh <unruh@invalid.ca> - 2015-04-15 06:20 +0000
Re: Keeping 'order' without RTC. Andrew Smallshaw <andrews@sdf.lonestar.org> - 2015-04-16 02:58 +0000
Re: Keeping 'order' without RTC. The Natural Philosopher <tnp@invalid.invalid> - 2015-04-16 05:21 +0100
Re: Keeping 'order' without RTC. Aragorn <thorongil@telenet.be.invalid> - 2015-04-16 11:42 +0200
Re: Keeping 'order' without RTC. Rob <nomail@example.com> - 2015-04-16 12:10 +0000
Re: Keeping 'order' without RTC. The Natural Philosopher <tnp@invalid.invalid> - 2015-04-16 13:42 +0100
Re: Keeping 'order' without RTC. Rob <nomail@example.com> - 2015-04-16 15:06 +0000
Re: Keeping 'order' without RTC. druck <news@druck.org.uk> - 2015-04-16 23:09 +0100
Re: Keeping 'order' without RTC. Michael Black <et472@ncf.ca> - 2015-04-16 14:17 -0400
Re: Keeping 'order' without RTC. Unknown <dog@gmail.com> - 2015-03-04 09:56 +0000
Re: Keeping 'order' without RTC. ruben safir <ruben@mrbrklyn.com> - 2015-04-16 06:13 -0400
Re: Keeping 'order' without RTC. The Natural Philosopher <tnp@invalid.invalid> - 2015-04-16 12:40 +0100
Re: Keeping 'order' without RTC. Baho Utot <baho-utot@columbus.rr.com> - 2015-04-16 16:32 -0400
Re: Keeping 'order' without RTC. William Unruh <unruh@invalid.ca> - 2015-04-17 01:54 +0000
Re: Keeping 'order' without RTC. The Natural Philosopher <tnp@invalid.invalid> - 2015-04-17 06:34 +0100
Re: Keeping 'order' without RTC. Dr J R Stockton <reply1500@merlyn.demon.co.uk.invalid> - 2015-04-18 23:13 +0100
Re: Keeping 'order' without RTC. John Hasler <jhasler@newsguy.com> - 2015-04-13 20:39 -0500
Re: Keeping 'order' without RTC. Rob <nomail@example.com> - 2015-04-14 06:46 +0000
Page 10 of 11 — ← Prev page 1 … 8 9 [10] 11 Next page →
| From | Richard Kettlewell <rjk@greenend.org.uk> |
|---|---|
| Date | 2015-05-12 19:03 +0100 |
| Message-ID | <wwv8uct7jwu.fsf@l1AntVDjLrnP7Td3DQJ8ynzIq3lJMueXf87AxnpFoA.invalid> |
| In reply to | #14771 |
William Unruh <unruh@invalid.ca> writes: > Richard Kettlewell <rjk@greenend.org.uk> wrote: >> TNP is right to say that each second of Unix time corresponds to a >> single second in UTC; formally speaking, there is an injective >> mapping > > That depends on what you mean by "every second of Unix time". I mean the possible values of time_t (or struct timespec etc) as interpreted by Unix systems. > Unix time, UTC time, etc are all concerned with how the seconds are > labeled. In Unix time, the leap seconds are either unlabeled, or in > (almost) all implimentations they are labeled with the same label as > the last second before the leap second. They are unlabelled. There is no value of time_t that corresponds to a leap second. The function converting a time_t to a UTC time is simply not capable of outputting a leap second. > I do not believe tht any computer in existence would, if asked for the > time on a leapsecond, return either and error, or an undefined. Indeed. So the clock (specifically, CLOCK_REALTIME) is incorrect near leap seconds. > On linux it returns the same label as the previous second. AFAIK that is only true if NTP is in use. But again, that just means the clock is temporarily wrong. > That ensure that the clock always advances-- a later reading gives a > later time. Pretty horrible if you are timing something, but... That’s what CLOCK_MONOTONIC is for. >> from Unix time to UTC. The reverse isn???t true, but I don???t think he (or >> anyone else) is claiming it is. As such ???Except leap seconds??? make no >> sense as a response, because there is no representation of them among >> ???every second of Unix time???. > > Sure there is. OK, what is the Unix time representation of 2012-06-30 23:59:60 UTC? -- http://www.greenend.org.uk/rjk/
[toc] | [prev] | [next] | [standalone]
| From | William Unruh <unruh@invalid.ca> |
|---|---|
| Date | 2015-05-12 18:26 +0000 |
| Message-ID | <mitgk9$acs$1@dont-email.me> |
| In reply to | #14776 |
On 2015-05-12, Richard Kettlewell <rjk@greenend.org.uk> wrote: > William Unruh <unruh@invalid.ca> writes: >> Richard Kettlewell <rjk@greenend.org.uk> wrote: > >>> TNP is right to say that each second of Unix time corresponds to a >>> single second in UTC; formally speaking, there is an injective >>> mapping >> >> That depends on what you mean by "every second of Unix time". > > I mean the possible values of time_t (or struct timespec etc) as > interpreted by Unix systems. > >> Unix time, UTC time, etc are all concerned with how the seconds are >> labeled. In Unix time, the leap seconds are either unlabeled, or in >> (almost) all implimentations they are labeled with the same label as >> the last second before the leap second. > > They are unlabelled. There is no value of time_t that corresponds to a > leap second. The function converting a time_t to a UTC time is simply > not capable of outputting a leap second. Well, Wikipedia begs to differ. Anyway if you could give me a reference for what you call Unix time, a reference from after the time when leapseconds were introduced, it would be helpful. Otherwise we will also simply be arguing about our own peculiar definitions of the terms. > >> I do not believe tht any computer in existence would, if asked for the >> time on a leapsecond, return either and error, or an undefined. > > Indeed. So the clock (specifically, CLOCK_REALTIME) is incorrect near > leap seconds. Again, this sounds more like your interpretation than any specification. > >> On linux it returns the same label as the previous second. > > AFAIK that is only true if NTP is in use. But again, that just means > the clock is temporarily wrong. Mills was involved in the design of the Linux time system, and that behaviour is part of the kernel behaviour AFAIK. > >> That ensure that the clock always advances-- a later reading gives a >> later time. Pretty horrible if you are timing something, but... > > That???s what CLOCK_MONOTONIC is for. > >>> from Unix time to UTC. The reverse isn???t true, but I don???t think he (or >>> anyone else) is claiming it is. As such ???Except leap seconds??? make no >>> sense as a response, because there is no representation of them among >>> ???every second of Unix time???. >> >> Sure there is. > > OK, what is the Unix time representation of 2012-06-30 23:59:60 UTC? > 23:59:59 or 0:0:0 ( in which case the next second is also 0:0:0)
[toc] | [prev] | [next] | [standalone]
| From | Richard Kettlewell <rjk@greenend.org.uk> |
|---|---|
| Date | 2015-05-12 19:59 +0100 |
| Message-ID | <wwv38317hb1.fsf@l1AntVDjLrnP7Td3DQJ8ynzIq3lJMueXf87AxnpFoA.invalid> |
| In reply to | #14777 |
William Unruh <unruh@invalid.ca> writes: > Richard Kettlewell <rjk@greenend.org.uk> wrote: >> They are unlabelled. There is no value of time_t that corresponds to a >> leap second. The function converting a time_t to a UTC time is simply >> not capable of outputting a leap second. > > Well, Wikipedia begs to differ. > Anyway if you could give me a reference for what you call Unix time, a > reference from after the time when leapseconds were introduced, it would > be helpful. Otherwise we will also simply be arguing about our own > peculiar definitions of the terms. “The number of seconds that have elapsed since 00:00:00 Coordinated Universal Time (UTC), Thursday, 1 January 1970, not counting leap seconds”. This is how functions such as gmtime() have always interpreted it. >>> I do not believe tht any computer in existence would, if asked for the >>> time on a leapsecond, return either and error, or an undefined. >> >> Indeed. So the clock (specifically, CLOCK_REALTIME) is incorrect near >> leap seconds. > > Again, this sounds more like your interpretation than any > specification. It’s just a consequence of the definition. There’s no way to represent leap seconds, therefore the clock is wrong during them. >>> On linux it returns the same label as the previous second. >> >> AFAIK that is only true if NTP is in use. But again, that just means >> the clock is temporarily wrong. > > Mills was involved in the design of the Linux time system, and that > behaviour is part of the kernel behaviour AFAIK. The behavior is in a file called ntp.c, which ought to be a hint. Where do you think the kernel learns about leap seconds from? If you’re not using NTP (or similar), it has no idea when they occur. >>>> from Unix time to UTC. The reverse isn???t true, but I don???t >>>> think he (or anyone else) is claiming it is. As such ???Except >>>> leap seconds??? make no sense as a response, because there is no >>>> representation of them among ???every second of Unix time???. >>> >>> Sure there is. >> >> OK, what is the Unix time representation of 2012-06-30 23:59:60 UTC? > > 23:59:59 or 0:0:0 ( in which case the next second is also 0:0:0) That’s not a Unix time. The answer to the question would be a time_t value. For instance, 1431456861 represents 2015-05-12 18:54:21 UTC. -- http://www.greenend.org.uk/rjk/
[toc] | [prev] | [next] | [standalone]
| From | William Unruh <unruh@invalid.ca> |
|---|---|
| Date | 2015-05-12 20:05 +0000 |
| Message-ID | <mitmdm$3oa$1@dont-email.me> |
| In reply to | #14779 |
On 2015-05-12, Richard Kettlewell <rjk@greenend.org.uk> wrote: > William Unruh <unruh@invalid.ca> writes: >> Richard Kettlewell <rjk@greenend.org.uk> wrote: >>> They are unlabelled. There is no value of time_t that corresponds to a >>> leap second. The function converting a time_t to a UTC time is simply >>> not capable of outputting a leap second. >> >> Well, Wikipedia begs to differ. > >> Anyway if you could give me a reference for what you call Unix time, a >> reference from after the time when leapseconds were introduced, it would >> be helpful. Otherwise we will also simply be arguing about our own >> peculiar definitions of the terms. > > ???The number of seconds that have elapsed since 00:00:00 Coordinated > Universal Time (UTC), Thursday, 1 January 1970, not counting leap > seconds???. This is how functions such as gmtime() have always > interpreted it. The question is how does your definition handle leap seconds while they are occuring, and what backing do you have for your definition? > >>>> I do not believe tht any computer in existence would, if asked for the >>>> time on a leapsecond, return either and error, or an undefined. >>> >>> Indeed. So the clock (specifically, CLOCK_REALTIME) is incorrect near >>> leap seconds. >> >> Again, this sounds more like your interpretation than any >> specification. > > It???s just a consequence of the definition. There???s no way to represent > leap seconds, therefore the clock is wrong during them. It is YOUR definition. Backing that anyone else uses it please. > >>>> On linux it returns the same label as the previous second. >>> >>> AFAIK that is only true if NTP is in use. But again, that just means >>> the clock is temporarily wrong. >> >> Mills was involved in the design of the Linux time system, and that >> behaviour is part of the kernel behaviour AFAIK. > > The behavior is in a file called ntp.c, which ought to be a hint. Where > do you think the kernel learns about leap seconds from? If you???re not > using NTP (or similar), it has no idea when they occur. No. That just means that David Mills, the developer of ntp was involved in defining the behaviour of the clock on Linux systems. You know better than to believe that the name defines the thing. > >>>>> from Unix time to UTC. The reverse isn???t true, but I don???t >>>>> think he (or anyone else) is claiming it is. As such ???Except >>>>> leap seconds??? make no sense as a response, because there is no >>>>> representation of them among ???every second of Unix time???. >>>> >>>> Sure there is. >>> >>> OK, what is the Unix time representation of 2012-06-30 23:59:60 UTC? >> >> 23:59:59 or 0:0:0 ( in which case the next second is also 0:0:0) > > That???s not a Unix time. The answer to the question would be a time_t > value. For instance, 1431456861 represents 2015-05-12 18:54:21 UTC. I am certainly NOT going to convert it to seconds. You may. My defintion was sufficient for you to figure out that on your own. >
[toc] | [prev] | [next] | [standalone]
| From | Richard Kettlewell <rjk@greenend.org.uk> |
|---|---|
| Date | 2015-05-12 22:58 +0100 |
| Message-ID | <wwvoalp5ugs.fsf@l1AntVDjLrnP7Td3DQJ8ynzIq3lJMueXf87AxnpFoA.invalid> |
| In reply to | #14781 |
William Unruh <unruh@invalid.ca> writes: > It is YOUR definition. Backing that anyone else uses it please. It’s not “my” definition. It corresponds to the behavior of gmtime() in Unix systems. If you think it has some other behavior then I can only repeat my challenge to produce a counterexample. >>>>> On linux it returns the same label as the previous second. >>>> >>>> AFAIK that is only true if NTP is in use. But again, that just means >>>> the clock is temporarily wrong. >>> >>> Mills was involved in the design of the Linux time system, and that >>> behaviour is part of the kernel behaviour AFAIK. >> >> The behavior is in a file called ntp.c, which ought to be a hint. >> Where do you think the kernel learns about leap seconds from? If >> you???re not using NTP (or similar), it has no idea when they occur. > > No. That just means that David Mills, the developer of ntp was > involved in defining the behaviour of the clock on Linux systems. You > know better than to believe that the name defines the thing. I repeat: where do you think the kernel learns about leap seconds from? -- http://www.greenend.org.uk/rjk/
[toc] | [prev] | [next] | [standalone]
| From | William Unruh <unruh@invalid.ca> |
|---|---|
| Date | 2015-05-13 01:15 +0000 |
| Message-ID | <miu8it$1cb$1@dont-email.me> |
| In reply to | #14784 |
On 2015-05-12, Richard Kettlewell <rjk@greenend.org.uk> wrote: > William Unruh <unruh@invalid.ca> writes: >> It is YOUR definition. Backing that anyone else uses it please. > > It???s not ???my??? definition. It corresponds to the behavior of gmtime() in > Unix systems. If you think it has some other behavior then I can only > repeat my challenge to produce a counterexample. Sure, I did. I told you how the kernel handles leap seconds. It is not undefined. I also told you how posix handles leap seconds. It is not undefined. As far as I can tell gmtime assumes that there are 86400 seconds day, and leap seconds are not counted. That is exactly what UTC does. But the question is how do they handle leap seconds while they are occuring. gmtime is not supposed to handle that. It takes in a number and produces a date, by assuming, no matter what that number is, that there are 86400 seconds per day. > >>>>>> On linux it returns the same label as the previous second. >>>>> >>>>> AFAIK that is only true if NTP is in use. But again, that just means >>>>> the clock is temporarily wrong. >>>> >>>> Mills was involved in the design of the Linux time system, and that >>>> behaviour is part of the kernel behaviour AFAIK. >>> >>> The behavior is in a file called ntp.c, which ought to be a hint. >>> Where do you think the kernel learns about leap seconds from? If >>> you???re not using NTP (or similar), it has no idea when they occur. >> >> No. That just means that David Mills, the developer of ntp was >> involved in defining the behaviour of the clock on Linux systems. You >> know better than to believe that the name defines the thing. > > I repeat: where do you think the kernel learns about leap seconds from? You can tell it, ntp can tell it, other programs can tell it. That is irrelevant. the question is what does it do with it. >
[toc] | [prev] | [next] | [standalone]
| From | The Natural Philosopher <tnp@invalid.invalid> |
|---|---|
| Date | 2015-05-13 08:14 +0100 |
| Message-ID | <miutka$tio$1@news.albasani.net> |
| In reply to | #14785 |
On 13/05/15 02:15, William Unruh wrote: > On 2015-05-12, Richard Kettlewell <rjk@greenend.org.uk> wrote: >> William Unruh <unruh@invalid.ca> writes: >>> It is YOUR definition. Backing that anyone else uses it please. >> >> It???s not ???my??? definition. It corresponds to the behavior of gmtime() in >> Unix systems. If you think it has some other behavior then I can only >> repeat my challenge to produce a counterexample. > > Sure, I did. I told you how the kernel handles leap seconds. The kernel doesn't handle leap seconds. Leap seconds are a human affectation. The kernel keeps UNIX time and thats all. > > You can tell it, ntp can tell it, other programs can tell it. > > That is irrelevant. the question is what does it do with it. >> Well it doesn't update the UNIX clock with it, that's for sure. -- Everything you read in newspapers is absolutely true, except for the rare story of which you happen to have first-hand knowledge. – Erwin Knoll
[toc] | [prev] | [next] | [standalone]
| From | Richard Kettlewell <rjk@greenend.org.uk> |
|---|---|
| Date | 2015-05-13 09:24 +0100 |
| Message-ID | <wwviobw6g1f.fsf@l1AntVDjLrnP7Td3DQJ8ynzIq3lJMueXf87AxnpFoA.invalid> |
| In reply to | #14785 |
William Unruh <unruh@invalid.ca> writes: > Richard Kettlewell <rjk@greenend.org.uk> wrote: >> William Unruh <unruh@invalid.ca> writes: >>> It is YOUR definition. Backing that anyone else uses it please. >> >> It???s not ???my??? definition. It corresponds to the behavior of >> gmtime() in Unix systems. If you think it has some other behavior >> then I can only repeat my challenge to produce a counterexample. > > Sure, I did. I told you how the kernel handles leap seconds. > It is not undefined. I also told you how posix handles leap seconds. It > is not undefined. The thing you have (still) failed to do is give a value X for which gmtime(X)=2012-06-30 23:59:60 UTC. > As far as I can tell gmtime assumes that there are 86400 seconds day, > and leap seconds are not counted. Yes. > That is exactly what UTC does. No. 2012-06-30 had 86401 UTC seconds. > But the question is how do they handle leap seconds while they are > occuring. gmtime is not supposed to handle that. It takes in a number > and produces a date, by assuming, no matter what that number is, that > there are 86400 seconds per day. The question was about ‘Unix time’. That’s precisely what the input to gmtime is. Based on previous discussion at this point you’re probably going to repeat your claim this is some personal definition unique to me, which is rather strange given ‘my’ definition is a straight quote from WP, matches the implementation, etc. In fact you are mostly arguing about the behavior of a particular configuration of a particular implementation of CLOCK_REALTIME. But that’s not the same thing as ‘Unix time’; it’s just one of several possible heuristics for dealing with leap seconds while returning a Unix time value. >>>>>>> On linux it returns the same label as the previous second. >>>>>> >>>>>> AFAIK that is only true if NTP is in use. But again, that just >>>>>> means the clock is temporarily wrong. >>>>> >>>>> Mills was involved in the design of the Linux time system, and that >>>>> behaviour is part of the kernel behaviour AFAIK. >>>> >>>> The behavior is in a file called ntp.c, which ought to be a hint. >>>> Where do you think the kernel learns about leap seconds from? If >>>> you???re not using NTP (or similar), it has no idea when they occur. >>> >>> No. That just means that David Mills, the developer of ntp was >>> involved in defining the behaviour of the clock on Linux systems. You >>> know better than to believe that the name defines the thing. >> >> I repeat: where do you think the kernel learns about leap seconds >> from? > > You can tell it, ntp can tell it, other programs can tell it. > > That is irrelevant. the question is what does it do with it. No, it is not irrelevant. You claimed “On linux it returns the same label as the previous second”. But this is only true if you use NTP (or some equivalent). If you don’t provide leap second information to the kernel then this behaviour will not occur. It’s perfectly possible to run a Linux system in which nothing supplies leap second information to the kernel and indeed this is true of many real systems. -- http://www.greenend.org.uk/rjk/
[toc] | [prev] | [next] | [standalone]
| From | John Hasler <jhasler@newsguy.com> |
|---|---|
| Date | 2015-05-12 11:50 -0500 |
| Message-ID | <87twvhn3j0.fsf@thumper.dhh.gt.org> |
| In reply to | #14768 |
William Unruh writes: > No, there is no designation of a leap second on Unix time. Unix time > will never return the designation above. It simply stops the clock for > that second making 23:59:59 two seconds long, not one. From the UNIX Programmer's Manual Volume 1 7th Edition, page 234: *Time* returns the time in seconds since 00:00:00 GMT Jan. 1, 1970, measured in seconds. Thus a stream of sequentially numbered seconds much like TAI. There could be no provision for leap seconds as they had not been invented in 1971 when the first edition came out. What I meant by "nobody uses UNIX time" was that (almost) everybody has always just set the clock from the nearest UTC source. -- John Hasler jhasler@newsguy.com Dancing Horse Hill Elmwood, WI USA
[toc] | [prev] | [next] | [standalone]
| From | The Natural Philosopher <tnp@invalid.invalid> |
|---|---|
| Date | 2015-05-12 18:52 +0100 |
| Message-ID | <miteks$ev$1@news.albasani.net> |
| In reply to | #14770 |
On 12/05/15 17:50, John Hasler wrote: > William Unruh writes: >> No, there is no designation of a leap second on Unix time. Unix time >> will never return the designation above. It simply stops the clock for >> that second making 23:59:59 two seconds long, not one. > > From the UNIX Programmer's Manual Volume 1 7th Edition, page 234: > > *Time* returns the time in seconds since 00:00:00 GMT Jan. 1, 1970, > measured in seconds. > > Thus a stream of sequentially numbered seconds much like TAI. There > could be no provision for leap seconds as they had not been invented > in 1971 when the first edition came out. > The point is that UNIX time is what it says it is - a monotonically increasing quantity that increases at a constant rate and is used to keep all the UNIX timings in sync. Real time as such - human time, -is derived from it by a set of library functions that handle leap years and seconds and centuries and daylight savings: That is however merely a human convemntion. The real unix time is just 'seconds since 1970' > What I meant by "nobody uses UNIX time" was that (almost) everybody has > always just set the clock from the nearest UTC source. > No they haven't. NTP sets it to the right UNIX time. And so too do any manual updates. They set the UNIX clock. by interpreting local time to be the correct unix time. I strongly suspect real time clocks of the battery backed flavour ALSO are only counting the seconds from 1970, too. All the 'user space' time is an illusion - a layer on top of UNIX time. -- Everything you read in newspapers is absolutely true, except for the rare story of which you happen to have first-hand knowledge. – Erwin Knoll
[toc] | [prev] | [next] | [standalone]
| From | c28f62@TheWorld.com (Mark Kramer) |
|---|---|
| Date | 2015-05-12 17:29 +0000 |
| Message-ID | <mitdal$eej$1@flea.killfile.org> |
| In reply to | #14768 |
In article <mit74b$338$1@dont-email.me>, William Unruh <unruh@invalid.ca> wrote: >No, there is no designation of a leap second on Unix time. Unix time >will never return the designation above. It simply stops the clock for >that second making 23:59:59 two seconds long, not one. The system clock does not stop "for that second". The system clock has no concept of leap seconds or when they are going to happen. If you have no time management other than the system clock, your system clock will be off by a second after a leap second occurs. That's where NTP comes in.
[toc] | [prev] | [next] | [standalone]
| From | William Unruh <unruh@invalid.ca> |
|---|---|
| Date | 2015-05-12 18:36 +0000 |
| Message-ID | <mith7r$epj$1@dont-email.me> |
| In reply to | #14772 |
On 2015-05-12, Mark Kramer <c28f62@TheWorld.com> wrote:
> In article <mit74b$338$1@dont-email.me>,
> William Unruh <unruh@invalid.ca> wrote:
>>No, there is no designation of a leap second on Unix time. Unix time
>>will never return the designation above. It simply stops the clock for
>>that second making 23:59:59 two seconds long, not one.
>
> The system clock does not stop "for that second". The system clock has no
> concept of leap seconds or when they are going to happen. If you have
> no time management other than the system clock, your system clock will be
> off by a second after a leap second occurs.
>
> That's where NTP comes in.
man adjtimex
(which is a linux system routine, not an ntp one)
For Linux kernels 2.0 through 2.6, the value is a sum of
these:
1 PLL updates enabled
2 PPS freq discipline enabled
4 PPS time discipline enabled
8 frequency-lock mode enabled
16 inserting leap second
32 deleting leap second
64 clock unsynchronized
128 holding frequency
256 PPS signal present
512 PPS signal jitter exceeded
1024 PPS signal wander exceeded
2048 PPS signal calibration error
4096 clock hardware fault
o
(AFAIK it still behaves the same way in kernels up to 4.1)
>
[toc] | [prev] | [next] | [standalone]
| From | Richard Kettlewell <rjk@greenend.org.uk> |
|---|---|
| Date | 2015-05-12 20:00 +0100 |
| Message-ID | <wwvwq0d62pi.fsf@l1AntVDjLrnP7Td3DQJ8ynzIq3lJMueXf87AxnpFoA.invalid> |
| In reply to | #14778 |
William Unruh <unruh@invalid.ca> writes: > On 2015-05-12, Mark Kramer <c28f62@TheWorld.com> wrote: >> William Unruh <unruh@invalid.ca> wrote: >>>No, there is no designation of a leap second on Unix time. Unix time >>>will never return the designation above. It simply stops the clock for >>>that second making 23:59:59 two seconds long, not one. >> >> The system clock does not stop "for that second". The system clock has no >> concept of leap seconds or when they are going to happen. If you have >> no time management other than the system clock, your system clock will be >> off by a second after a leap second occurs. >> >> That's where NTP comes in. > > man adjtimex > (which is a linux system routine, not an ntp one) And what do you think calls it? -- http://www.greenend.org.uk/rjk/
[toc] | [prev] | [next] | [standalone]
| From | William Unruh <unruh@invalid.ca> |
|---|---|
| Date | 2015-05-12 20:06 +0000 |
| Message-ID | <mitmfh$3oa$2@dont-email.me> |
| In reply to | #14780 |
On 2015-05-12, Richard Kettlewell <rjk@greenend.org.uk> wrote: > William Unruh <unruh@invalid.ca> writes: >> On 2015-05-12, Mark Kramer <c28f62@TheWorld.com> wrote: >>> William Unruh <unruh@invalid.ca> wrote: >>>>No, there is no designation of a leap second on Unix time. Unix time >>>>will never return the designation above. It simply stops the clock for >>>>that second making 23:59:59 two seconds long, not one. >>> >>> The system clock does not stop "for that second". The system clock has no >>> concept of leap seconds or when they are going to happen. If you have >>> no time management other than the system clock, your system clock will be >>> off by a second after a leap second occurs. >>> >>> That's where NTP comes in. >> >> man adjtimex >> (which is a linux system routine, not an ntp one) > > And what do you think calls it? Anything that wants to call it. It is a system routine not an ntp routine. If you do not install ntp you still have that routine. >
[toc] | [prev] | [next] | [standalone]
| From | c28f62@TheWorld.com (Mark Kramer) |
|---|---|
| Date | 2015-05-12 06:14 +0000 |
| Message-ID | <mis5on$5no$1@flea.killfile.org> |
| In reply to | #14701 |
In article <mi8djo$6cf$1@dont-email.me>, William Unruh <unruh@invalid.ca> wrote: >Agreed. But there is still a well defined algorithm. The RTC is worse. >As far as I know, it never takes leap seconds into account. Of course it doesn't. It's a simple device. >Fortunately it is usually recalibrated on shutdown, It may be set on shutdown, or it may be set more often. There is no "calibration". >so the system, which should take >leap seconds into account ( although I am not sure Windows does) can >reinitialise the RTC. The system doesn't know leap seconds either. It counts interrupts. There are demons that run on the system that monitor external time sources, like an NTP demon would. Windows (since at least NT and XP) have NTP clients built in, so in your terminology, yes, of course "Windows" takes leap seconnds into account. It may not do that for a week, but it will eventually do it. If you are that interested in keeping up with leap seconds and are using Windows, then you will almost certainly be using a more frequent update interval for the Windows internal NTP client, or be using a third-party client.
[toc] | [prev] | [next] | [standalone]
| From | c28f62@TheWorld.com (Mark Kramer) |
|---|---|
| Date | 2015-05-12 06:09 +0000 |
| Message-ID | <mis5e4$56e$1@flea.killfile.org> |
| In reply to | #14698 |
In article <mi6tei$qmd$1@dont-email.me>, William Unruh <unruh@invalid.ca> wrote: >On 2015-05-04, Mark Kramer <c28f62@TheWorld.com> wrote: >> The software clock is not an RTC. It counts interrupts. Yes, you can >> decode that count to a wallclock time, but that extra step is an extra >> step for a true RTC. > >Agreed. It counts "seconds" (well after it has been calibrated) No, it counts interrupts. The frequency of interrupts depends on the hardware. For old DOS on a PC, it was 18.2Hz. For some linuxes I've used, it is 1kHz. Some were, as I recall, 100Hz. >but >those are at best "seconds since the machine has been turned on". Since that counter can be set to any value, and is set by the time-setting commands, no, it isn't "at best" a simple counter of power-on ticks, it is "at best" a counter of some multiple of seconds since 1 Jan 1970 0000 GMT. >To >have it count useful seconds (eg seconds since Jan 1 1970) you need to >feed it the Real Time at one of those seconds. Taht is the job of the >Real Time Clock. Which the Pi does not have unless you've added that hardware. Otherwise, it is the job of the user, or of the NTP demon. >Note that the Real Time Clock also counts seconds. I've had an RTC that did quite well at counting 0.01 seconds. None of them I know actually count seconds. They count to 60 and then go back to 0 while incrementing a counter called "minutes". A 32.something kHz crystal is very common. >Seconds since epoch IS a "real time" Seconds since the computer was >switched on is not. Seconds since epoch is not "real time". It is a count of seconds since an arbitrary point in time. >> On the other hand, the true RTC devices do maintain the "real time". >> You can ask it directly "what hour of the day is it?" because its API >> returns hour of the day. You don't have to get a 32 or 64 bit integer and > >Actually intrnally it too just keeps count of seconds. No. It keeps count of seconds of the minute, minute of the hour, hour of the day, etc...
[toc] | [prev] | [next] | [standalone]
| From | William Unruh <unruh@invalid.ca> |
|---|---|
| Date | 2015-05-12 06:44 +0000 |
| Message-ID | <mis7h7$a7m$1@dont-email.me> |
| In reply to | #14762 |
On 2015-05-12, Mark Kramer <c28f62@TheWorld.com> wrote:
> In article <mi6tei$qmd$1@dont-email.me>,
> William Unruh <unruh@invalid.ca> wrote:
>>On 2015-05-04, Mark Kramer <c28f62@TheWorld.com> wrote:
>>> The software clock is not an RTC. It counts interrupts. Yes, you can
>>> decode that count to a wallclock time, but that extra step is an extra
>>> step for a true RTC.
>>
>>Agreed. It counts "seconds" (well after it has been calibrated)
>
> No, it counts interrupts. The frequency of interrupts depends on the
> hardware. For old DOS on a PC, it was 18.2Hz. For some linuxes I've used,
> it is 1kHz. Some were, as I recall, 100Hz.
Sheesh. You cannot read? ("well after it has been calibrated")
>
>>but
>>those are at best "seconds since the machine has been turned on".
>
> Since that counter can be set to any value, and is set by the time-setting
> commands, no, it isn't "at best" a simple counter of power-on ticks, it is
> "at best" a counter of some multiple of seconds since 1 Jan 1970 0000 GMT.
The counter counts interrupts as you say ( or seconds ) but unless you
tell it what time it started it cannot do anything but count seconds
since the computer was turned on. IF from outside you tell it that it
started at some number of seconds after Jan 1 1970, then yes, it can add
that to the number of counts to get seconds since epoch.
>
>>To
>>have it count useful seconds (eg seconds since Jan 1 1970) you need to
>>feed it the Real Time at one of those seconds. Taht is the job of the
>>Real Time Clock.
>
> Which the Pi does not have unless you've added that hardware. Otherwise,
> it is the job of the user, or of the NTP demon.
Precisely.
>
>>Note that the Real Time Clock also counts seconds.
>
> I've had an RTC that did quite well at counting 0.01 seconds. None of
> them I know actually count seconds. They count to 60 and then go back
> to 0 while incrementing a counter called "minutes". A 32.something kHz
> crystal is very common.
>
>>Seconds since epoch IS a "real time" Seconds since the computer was
>>switched on is not.
>
> Seconds since epoch is not "real time". It is a count of seconds since an
> arbitrary point in time.
Since you know epoch you know what the real time is. (and yes, real time
is somewhat arbitrary.24 hours in a day, 60 min/hour, 60 sec per minute
is an "arbitary" but by now universally agreed on division of time.
>
>>> On the other hand, the true RTC devices do maintain the "real time".
>>> You can ask it directly "what hour of the day is it?" because its API
>>> returns hour of the day. You don't have to get a 32 or 64 bit integer and
>>
>>Actually intrnally it too just keeps count of seconds.
>
> No. It keeps count of seconds of the minute, minute of the hour, hour
> of the day, etc...
Well, you may be right, or it may count seconds and convert internall. I
do not know which it does, and suspect different RTCs behave differently
internally.
>
[toc] | [prev] | [next] | [standalone]
| From | c28f62@TheWorld.com (Mark Kramer) |
|---|---|
| Date | 2015-05-12 17:45 +0000 |
| Message-ID | <mite7f$hgn$1@flea.killfile.org> |
| In reply to | #14765 |
In article <mis7h7$a7m$1@dont-email.me>,
William Unruh <unruh@invalid.ca> wrote:
>On 2015-05-12, Mark Kramer <c28f62@TheWorld.com> wrote:
>> In article <mi6tei$qmd$1@dont-email.me>,
>> William Unruh <unruh@invalid.ca> wrote:
>>>On 2015-05-04, Mark Kramer <c28f62@TheWorld.com> wrote:
>>>> The software clock is not an RTC. It counts interrupts. Yes, you can
>>>> decode that count to a wallclock time, but that extra step is an extra
>>>> step for a true RTC.
>>>
>>>Agreed. It counts "seconds" (well after it has been calibrated)
>>
>> No, it counts interrupts. The frequency of interrupts depends on the
>> hardware. For old DOS on a PC, it was 18.2Hz. For some linuxes I've used,
>> it is 1kHz. Some were, as I recall, 100Hz.
>
>Sheesh. You cannot read? ("well after it has been calibrated")
You can "calibrate" it all you want, and you can look at it immediately
after this "calibration" or well after it has been, but it still counts
interrupts, not seconds. If your system clock has a 1Hz interrupt feeding
it, you have a very odd and very unusual system.
You agreed when I said it counted interrupts, and then claimed it
counts seconds (after some nebulous "calibration" step that you didn't
define.) The only "calibration" of the interrupt source I know of is when
NTP determines the drift of that clock and attempts to correct for it.
>> Since that counter can be set to any value, and is set by the time-setting
>> commands, no, it isn't "at best" a simple counter of power-on ticks, it is
>> "at best" a counter of some multiple of seconds since 1 Jan 1970 0000 GMT.
>
>The counter counts interrupts as you say ( or seconds )
Pick one and stay with it. The correct answer is it counts interrupts,
which are NOT "seconds".
>but unless you tell it what time it started
You don't have to tell it what time it started.
>it cannot do anything but count seconds
>since the computer was turned on.
That's not true. The old DOS "clock", for example, counted interrupts
at a rate of 18.2Hz until that counter reached a predetermined value
and then it was reset to 0. And the clocks on many of the linux systems
I manage count milliseconds. The SGIs I have count nanoseconds in hardware
as well as whatever the system clock interrupts are.
>> Which the Pi does not have unless you've added that hardware. Otherwise,
>> it is the job of the user, or of the NTP demon.
>
>Precisely.
Then stop saying that the Pi has an RTC, and please stop pretending that
the system clock it has counts "seconds" and not interrupts.
>Since you know epoch you know what the real time is.
No, I have a number that represents the number of seconds since a
specified time. I still must convert that to a real time.
[toc] | [prev] | [next] | [standalone]
| From | The Natural Philosopher <tnp@invalid.invalid> |
|---|---|
| Date | 2015-05-12 21:06 +0100 |
| Message-ID | <mitmh3$gan$1@news.albasani.net> |
| In reply to | #14773 |
On 12/05/15 18:45, Mark Kramer wrote:
> In article <mis7h7$a7m$1@dont-email.me>,
> William Unruh <unruh@invalid.ca> wrote:
>> On 2015-05-12, Mark Kramer <c28f62@TheWorld.com> wrote:
>>> In article <mi6tei$qmd$1@dont-email.me>,
>>> William Unruh <unruh@invalid.ca> wrote:
>>>> On 2015-05-04, Mark Kramer <c28f62@TheWorld.com> wrote:
>>>>> The software clock is not an RTC. It counts interrupts. Yes, you can
>>>>> decode that count to a wallclock time, but that extra step is an extra
>>>>> step for a true RTC.
>>>>
>>>> Agreed. It counts "seconds" (well after it has been calibrated)
>>>
>>> No, it counts interrupts. The frequency of interrupts depends on the
>>> hardware. For old DOS on a PC, it was 18.2Hz. For some linuxes I've used,
>>> it is 1kHz. Some were, as I recall, 100Hz.
>>
>> Sheesh. You cannot read? ("well after it has been calibrated")
>
> You can "calibrate" it all you want, and you can look at it immediately
> after this "calibration" or well after it has been, but it still counts
> interrupts, not seconds. If your system clock has a 1Hz interrupt feeding
> it, you have a very odd and very unusual system.
>
> You agreed when I said it counted interrupts, and then claimed it
> counts seconds (after some nebulous "calibration" step that you didn't
> define.) The only "calibration" of the interrupt source I know of is when
> NTP determines the drift of that clock and attempts to correct for it.
>
>>> Since that counter can be set to any value, and is set by the time-setting
>>> commands, no, it isn't "at best" a simple counter of power-on ticks, it is
>>> "at best" a counter of some multiple of seconds since 1 Jan 1970 0000 GMT.
>>
>> The counter counts interrupts as you say ( or seconds )
>
> Pick one and stay with it. The correct answer is it counts interrupts,
> which are NOT "seconds".
>
>> but unless you tell it what time it started
>
> You don't have to tell it what time it started.
>
>> it cannot do anything but count seconds
>> since the computer was turned on.
>
> That's not true. The old DOS "clock", for example, counted interrupts
> at a rate of 18.2Hz until that counter reached a predetermined value
> and then it was reset to 0. And the clocks on many of the linux systems
> I manage count milliseconds. The SGIs I have count nanoseconds in hardware
> as well as whatever the system clock interrupts are.
>
>>> Which the Pi does not have unless you've added that hardware. Otherwise,
>>> it is the job of the user, or of the NTP demon.
>>
>> Precisely.
>
> Then stop saying that the Pi has an RTC, and please stop pretending that
> the system clock it has counts "seconds" and not interrupts.
if there are a precise number of interrupts per second, its counting
seconds innit?
Streewth
>
>> Since you know epoch you know what the real time is.
>
> No, I have a number that represents the number of seconds since a
> specified time. I still must convert that to a real time.
>
--
Everything you read in newspapers is absolutely true, except for the
rare story of which you happen to have first-hand knowledge. – Erwin Knoll
[toc] | [prev] | [next] | [standalone]
| From | William Unruh <unruh@invalid.ca> |
|---|---|
| Date | 2015-04-14 23:18 +0000 |
| Message-ID | <mgk78f$i3i$2@dont-email.me> |
| In reply to | #14510 |
On 2015-04-12, Michael Black <et472@ncf.ca> wrote: > On Sun, 12 Apr 2015, Unknown wrote: > >> On Wed, 11 Mar 2015 13:20:06 +0000, Joe Beanfish wrote: >> >>> On Wed, 11 Mar 2015 04:53:11 +0000, Unknown wrote: >>>> So, back to the algorithm: >>>> the mathematical concept 'order' [as emphasised in the "Subject:"] is >>>> key. When Newton was called away from his desk of paper-work, he >>>> needed the papers to be 'stacked' in the same ORDER when he returned. >>>> Even if the cleaning-lady, had 'been there' during his absence, and >>>> <accessed the files>, provided the 'order' was maintained, the >>>> real-time attributes were not needed. >>> >>> One option, forget the idea of timestamps entirely. Name the files with >>> sequential numbers. Be sure to zero pad so ls works as expected. You >>> could even do the Basic programming trick of skipping numbers (e.g. by >>> 10s) so you could insert items higher in the queue without renumbering. >>> >>> 000000010-playme.mp3 >>> 000000020-thesis.mp3 >>> 000000030-soothing.mp3 >>> 000000040-jamz.mp3 >>> >>> uh-oh, breaking news, add >>> 000000000-sungoingnova.mp3 >> >> That's the kind if original good idea which we need !! >> With the 'thread overflow' I nearly missed this 1 month old post. >> I'll try to implement your idea, when I've cleared the chaos. >> > And the Raspberry Pi can't run without a Real Time Clock. Sorry, you are confused. RPi runs with a system clock. But it has no Real Time clock (RTC) unless you add a harware dongle. Yes, the RPi keeps time. But it starts out at Jan 1 1970 each time you reboot. > > You wasted all this time because you pretended to no know that. > > Linux needs to be interrupted to actually work, so keeping time > is intrinsic to the operating system. > > Like I said way back when, all you have to do is set the time and date > when you start the Pi up, something that used to be quite common. A > hardware clock is only used to set the time when the computer starts, > saving you a few keystrokes, the Pi or any Linux computer doesn't get time > from the hardware clock other times (unless someone is configuring it > differently, and a common thing then is to access a cesium standard on the > internet, which would be another way do to this if the Pi is networked). The hardware clock as you call it has been called the Real time clock since the first IBM PC.40 years ago. Your suggestion that every time the computer is switched on the operator enter in the correct time by hand is certainly one possibility. But computers are supposed to make life easier, not add yet another task, which is sometimes impossible (eg the RPI is floating over the Pacific in a balloon and it resets due to a power interruption). So, please do not get so self righteous. > > You waste everyone's time, and now thing some roundabout method is "good", > when it is all about you being too lazy to set the time when you turn on > the computer. > > Michael >
[toc] | [prev] | [next] | [standalone]
Page 10 of 11 — ← Prev page 1 … 8 9 [10] 11 Next page →
Back to top | Article view | comp.os.linux.misc
csiph-web