Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > sci.physics.relativity > #665208 > unrolled thread
| Started by | Maciej Woźniak <mlwozniak@wp.pl> |
|---|---|
| First post | 2025-07-22 12:33 +0200 |
| Last post | 2025-08-01 19:52 +0000 |
| Articles | 20 on this page of 211 — 25 participants |
Back to article view | Back to sci.physics.relativity
About the difference between "time dilation" and "clock error" Maciej Woźniak <mlwozniak@wp.pl> - 2025-07-22 12:33 +0200
Re: About the difference between "time dilation" and "clock error" Python <jp@python.invalid> - 2025-07-22 15:08 +0000
Re: About the difference between "time dilation" and "clock error" Maciej Woźniak <mlwozniak@wp.pl> - 2025-07-22 18:17 +0200
Re: About the difference between "time dilation" and "clock error" Python <jp@python.invalid> - 2025-07-22 17:56 +0000
Re: About the difference between "time dilation" and "clock error" Maciej Woźniak <mlwozniak@wp.pl> - 2025-07-22 21:11 +0200
Re: About the difference between "time dilation" and "clock error" Python <jp@python.invalid> - 2025-07-22 19:53 +0000
Re: About the difference between "time dilation" and "clock error" Maciej Woźniak <mlwozniak@wp.pl> - 2025-07-23 09:01 +0200
Re: About the difference between "time dilation" and "clock error" Python <jp@python.invalid> - 2025-07-23 11:28 +0000
Re: About the difference between "time dilation" and "clock error" Richard Hachel <rh@tiscali.fr> - 2025-07-22 16:41 +0000
Re: About the difference between "time dilation" and "clock error" Victo Balahovsky <ihio@tiv.ru> - 2025-07-22 18:50 +0000
Re: About the difference between "time dilation" and "clock error" Thomas Heger <ttt_heg@web.de> - 2025-07-29 09:48 +0200
Re: About the difference between "time dilation" and "clock error" "Paul.B.Andersen" <relativity@paulba.no> - 2025-07-29 22:02 +0200
Re: About the difference between "time dilation" and "clock error" Maciej Woźniak <mlwozniak@wp.pl> - 2025-07-30 07:08 +0200
Re: About the difference between "time dilation" and "clock error" "Paul B. Andersen" <relativity@paulba.no> - 2025-08-02 12:31 +0200
Re: About the difference between "time dilation" and "clock error" Maciej Woźniak <mlwozniak@wp.pl> - 2025-08-02 13:52 +0200
Re: About the difference between "time dilation" and "clock error" Python <jp@python.invalid> - 2025-08-02 12:01 +0000
Re: About the difference between "time dilation" and "clock error" Maciej Woźniak <mlwozniak@wp.pl> - 2025-08-02 14:17 +0200
Re: About the difference between "time dilation" and "clock error" Python <jp@python.invalid> - 2025-08-02 12:36 +0000
Re: About the difference between "time dilation" and "clock error" Maciej Woźniak <mlwozniak@wp.pl> - 2025-08-02 17:26 +0200
Re: About the difference between "time dilation" and "clock error" Python <jp@python.invalid> - 2025-08-02 17:14 +0000
Re: About the difference between "time dilation" and "clock error" Maciej Woźniak <mlwozniak@wp.pl> - 2025-08-02 19:29 +0200
Re: About the difference between "time dilation" and "clock error" Python <jp@python.invalid> - 2025-08-02 18:28 +0000
Re: About the difference between "time dilation" and "clock error" Maciej Woźniak <mlwozniak@wp.pl> - 2025-08-02 21:22 +0200
Re: About the difference between "time dilation" and "clock error" Herman Katsushika <shek@unrkaas.jp> - 2025-08-02 22:13 +0000
Re: About the difference between "time dilation" and "clock error" "Paul B. Andersen" <relativity@paulba.no> - 2025-08-06 22:39 +0200
Re: About the difference between "time dilation" and "clock error" Maciej Woźniak <mlwozniak@wp.pl> - 2025-08-07 08:54 +0200
Re: About the difference between "time dilation" and "clock error" "Paul B. Andersen" <relativity@paulba.no> - 2025-08-07 22:52 +0200
Re: About the difference between "time dilation" and "clock error" Maciej Woźniak <mlwozniak@wp.pl> - 2025-08-08 07:22 +0200
Re: About the difference between "time dilation" and "clock error" "Paul B. Andersen" <relativity@paulba.no> - 2025-08-08 13:51 +0200
Re: About the difference between "time dilation" and "clock error" Maciej Woźniak <mlwozniak@wp.pl> - 2025-08-08 15:09 +0200
Re: About the difference between "time dilation" and "clock error" Hyram Dubanowski <akaao@dhswua.pl> - 2025-08-08 17:03 +0000
Re: About the difference between "time dilation" and "clock error" "Paul B. Andersen" <relativity@paulba.no> - 2025-08-08 20:58 +0200
Re: About the difference between "time dilation" and "clock error" Maciej Woźniak <mlwozniak@wp.pl> - 2025-08-09 00:58 +0200
Re: About the difference between "time dilation" and "clock error" "Paul B. Andersen" <relativity@paulba.no> - 2025-08-09 13:46 +0200
Re: About the difference between "time dilation" and "clock error" Maciej Woźniak <mlwozniak@wp.pl> - 2025-08-09 20:18 +0200
Re: About the difference between "time dilation" and "clock error" "Paul B. Andersen" <relativity@paulba.no> - 2025-08-10 20:54 +0200
Re: About the difference between "time dilation" and "clock error" Maciej Woźniak <mlwozniak@wp.pl> - 2025-08-10 23:14 +0200
Re: About the difference between "time dilation" and "clock error" Leron Warszawski <nkan@rwsirr.pl> - 2025-08-03 14:08 +0000
Re: About the difference between "time dilation" and "clock error" nospam@de-ster.demon.nl (J. J. Lodder) - 2025-08-08 22:52 +0200
Re: About the difference between "time dilation" and "clock error" Maciej Woźniak <mlwozniak@wp.pl> - 2025-08-09 00:55 +0200
Re: About the difference between "time dilation" and "clock error" Python <jp@python.invalid> - 2025-07-30 10:54 +0000
Re: About the difference between "time dilation" and "clock error" "Paul B. Andersen" <relativity@paulba.no> - 2025-08-02 12:35 +0200
Re: About the difference between "time dilation" and "clock error" Thomas Heger <ttt_heg@web.de> - 2025-08-03 08:13 +0200
Re: About the difference between "time dilation" and "clock error" Python <jp@python.invalid> - 2025-08-03 07:39 +0000
Re: About the difference between "time dilation" and "clock error" "Paul.B.Andersen" <relativity@paulba.no> - 2025-08-04 14:04 +0200
Re: About the difference between "time dilation" and "clock error" Thomas Heger <ttt_heg@web.de> - 2025-08-05 08:48 +0200
Re: About the difference between "time dilation" and "clock error" "Paul.B.Andersen" <relativity@paulba.no> - 2025-08-05 15:14 +0200
Re: About the difference between "time dilation" and "clock error" Maciej Woźniak <mlwozniak@wp.pl> - 2025-08-05 16:53 +0200
Re: About the difference between "time dilation" and "clock error" Thomas Heger <ttt_heg@web.de> - 2025-08-06 08:34 +0200
Re: About the difference between "time dilation" and "clock error" "Paul.B.Andersen" <relativity@paulba.no> - 2025-08-06 22:17 +0200
Re: About the difference between "time dilation" and "clock error" Thomas Heger <ttt_heg@web.de> - 2025-08-07 08:41 +0200
Re: About the difference between "time dilation" and "clock error" "Paul.B.Andersen" <relativity@paulba.no> - 2025-08-07 22:13 +0200
Re: About the difference between "time dilation" and "clock error" Abner Habibulaev <baee@lvl.ru> - 2025-08-07 22:07 +0000
Re: About the difference between "time dilation" and "clock error" Python <jp@python.invalid> - 2025-08-08 16:04 +0000
Re: About the difference between "time dilation" and "clock error" "Paul.B.Andersen" <relativity@paulba.no> - 2025-08-08 20:31 +0200
Re: About the difference between "time dilation" and "clock error" Python <jp@python.invalid> - 2025-08-08 18:41 +0000
Re: About the difference between "time dilation" and "clock error" "Paul.B.Andersen" <relativity@paulba.no> - 2025-08-09 12:44 +0200
Re: About the difference between "time dilation" and "clock error" Maciej Woźniak <mlwozniak@wp.pl> - 2025-08-09 18:13 +0200
Re: About the difference between "time dilation" and "clock error" "Paul B. Andersen" <relativity@paulba.no> - 2025-08-09 19:40 +0200
Re: About the difference between "time dilation" and "clock error" Maciej Woźniak <mlwozniak@wp.pl> - 2025-08-09 20:18 +0200
Re: About the difference between "time dilation" and "clock error" Richard Hachel <rh@tiscali.fr> - 2025-08-09 11:22 +0000
Re: About the difference between "time dilation" and "clock error" Athel Cornish-Bowden <me@yahoo.com> - 2025-08-09 15:33 +0200
Re: About the difference between "time dilation" and "clock error" Python <jp@python.invalid> - 2025-08-09 13:40 +0000
Re: About the difference between "time dilation" and "clock error" Richard Hachel <rh@tiscali.fr> - 2025-08-09 14:49 +0000
Re: About the difference between "time dilation" and "clock error" Python <jp@python.invalid> - 2025-08-09 14:58 +0000
Re: About the difference between "time dilation" and "clock error" Richard Hachel <rh@tiscali.fr> - 2025-08-09 15:19 +0000
Re: About the difference between "time dilation" and "clock error" Thomas Heger <ttt_heg@web.de> - 2025-08-10 06:54 +0200
Re: About the difference between "time dilation" and "clock error" Ross Finlayson <ross.a.finlayson@gmail.com> - 2025-08-10 08:20 -0700
Re: About the difference between "time dilation" and "clock error" Shane Dubenkov <bdneb@nbanb.ru> - 2025-08-10 15:33 +0000
Re: About the difference between "time dilation" and "clock error" Ross Finlayson <ross.a.finlayson@gmail.com> - 2025-08-10 09:46 -0700
Re: About the difference between "time dilation" and "clock error" Ross Finlayson <ross.a.finlayson@gmail.com> - 2025-08-10 09:55 -0700
Re: About the difference between "time dilation" and "clock error" Ross Finlayson <ross.a.finlayson@gmail.com> - 2026-01-21 20:34 -0800
Re: About the difference between "time dilation" and "clock error" Ross Finlayson <ross.a.finlayson@gmail.com> - 2025-12-08 13:03 -0800
Re: About the difference between "time dilation" and "clock error" Thomas Heger <ttt_heg@web.de> - 2025-08-11 07:02 +0200
Re: About the difference between "time dilation" and "clock error" Freeman Vandroogenbroeck <dronn@reaea.nl> - 2025-08-12 21:42 +0000
Re: About the difference between "time dilation" and "clock error" "Paul.B.Andersen" <relativity@paulba.no> - 2025-08-10 21:05 +0200
Re: About the difference between "time dilation" and "clock error" Athel Cornish-Bowden <me@yahoo.com> - 2025-08-11 10:17 +0200
Re: About the difference between "time dilation" and "clock error" Thomas Heger <ttt_heg@web.de> - 2025-08-13 09:53 +0200
Re: About the difference between "time dilation" and "clock error" Thomas Heger <ttt_heg@web.de> - 2025-08-10 06:31 +0200
Re: About the difference between "time dilation" and "clock error" "Paul.B.Andersen" <relativity@paulba.no> - 2025-08-10 21:11 +0200
Re: About the difference between "time dilation" and "clock error" Murel Kartuzov <kv@ltel.ru> - 2025-08-10 20:35 +0000
Re: About the difference between "time dilation" and "clock error" "Paul B. Andersen" <relativity@paulba.no> - 2025-08-11 10:41 +0200
Re: About the difference between "time dilation" and "clock error" Maciej Woźniak <mlwozniak@wp.pl> - 2025-08-11 11:20 +0200
Re: About the difference between "time dilation" and "clock error" Darby Myachkov <vkbcm@yaycvbbm.ru> - 2025-08-12 20:45 +0000
Re: About the difference between "time dilation" and "clock error" Thomas Heger <ttt_heg@web.de> - 2025-08-13 10:00 +0200
Re: About the difference between "time dilation" and "clock error" Thomas Heger <ttt_heg@web.de> - 2025-08-14 07:54 +0200
Re: About the difference between "time dilation" and "clock error" Bladimir Natalenko <ilr@el.ru> - 2025-08-14 09:07 +0000
Re: About the difference between "time dilation" and "clock error" Python <jp@python.invalid> - 2025-08-14 12:17 +0000
Re: About the difference between "time dilation" and "clock error" "Paul.B.Andersen" <relativity@paulba.no> - 2025-08-17 22:34 +0200
Re: About the difference between "time dilation" and "clock error" Maciej Woźniak <mlwozniak@wp.pl> - 2025-08-18 07:52 +0200
Re: About the difference between "time dilation" and "clock error" Thomas Heger <ttt_heg@web.de> - 2025-08-18 09:36 +0200
Re: About the difference between "time dilation" and "clock error" "Paul.B.Andersen" <relativity@paulba.no> - 2025-08-18 20:56 +0200
Re: About the difference between "time dilation" and "clock error" Maciej Woźniak <mlwozniak@wp.pl> - 2025-08-18 21:30 +0200
Re: About the difference between "time dilation" and "clock error" Python <jp@python.invalid> - 2025-08-18 21:39 +0000
Re: About the difference between "time dilation" and "clock error" Maciej Woźniak <mlwozniak@wp.pl> - 2025-08-19 06:12 +0200
Re: About the difference between "time dilation" and "clock error" Richard Hachel <rh@tiscali.fr> - 2025-08-19 02:16 +0000
Re: About the difference between "time dilation" and "clock error" Thomas Heger <ttt_heg@web.de> - 2025-08-19 08:03 +0200
Re: About the difference between "time dilation" and "clock error" Richard Hachel <rh@tiscali.fr> - 2025-08-19 14:36 +0000
Re: About the difference between "time dilation" and "clock error" Richard Hachel <rh@tiscali.fr> - 2025-08-19 02:18 +0000
Re: About the difference between "time dilation" and "clock error" Richard Hachel <rh@tiscali.fr> - 2025-08-19 02:20 +0000
Re: About the difference between "time dilation" and "clock error" Richard Hachel <rh@tiscali.fr> - 2025-08-19 02:20 +0000
Re: About the difference between "time dilation" and "clock error" Thomas Heger <ttt_heg@web.de> - 2025-08-19 07:55 +0200
Re: About the difference between "time dilation" and "clock error" "Paul.B.Andersen" <relativity@paulba.no> - 2025-08-19 19:47 +0200
Re: About the difference between "time dilation" and "clock error" Richard Hachel <rh@tiscali.fr> - 2025-08-19 20:54 +0000
Re: About the difference between "time dilation" and "clock error" "Paul.B.Andersen" <relativity@paulba.no> - 2025-08-20 09:36 +0200
Re: About the difference between "time dilation" and "clock error" Thomas Heger <ttt_heg@web.de> - 2025-08-20 10:20 +0200
Re: About the difference between "time dilation" and "clock error" Richard Hachel <rh@tiscali.fr> - 2025-08-20 13:18 +0000
Re: About the difference between "time dilation" and "clock error" Python <jp@python.invalid> - 2025-08-20 13:27 +0000
Re: About the difference between "time dilation" and "clock error" Maciej Woźniak <mlwozniak@wp.pl> - 2025-08-20 15:36 +0200
Re: About the difference between "time dilation" and "clock error" Python <jp@python.invalid> - 2025-08-20 13:51 +0000
Re: About the difference between "time dilation" and "clock error" Richard Hachel <rh@tiscali.fr> - 2025-08-20 13:56 +0000
Re: About the difference between "time dilation" and "clock error" Python <jp@python.invalid> - 2025-08-20 13:58 +0000
Re: About the difference between "time dilation" and "clock error" Richard Hachel <rh@tiscali.fr> - 2025-08-20 13:59 +0000
Re: About the difference between "time dilation" and "clock error" Python <jp@python.invalid> - 2025-08-21 11:14 +0000
Re: About the difference between "time dilation" and "clock error" Richard Hachel <rh@tiscali.fr> - 2025-08-21 14:42 +0000
Re: About the difference between "time dilation" and "clock error" Maciej Woźniak <mlwozniak@wp.pl> - 2025-08-20 15:56 +0200
Re: About the difference between "time dilation" and "clock error" Richard Hachel <rh@tiscali.fr> - 2025-08-20 13:58 +0000
Re: About the difference between "time dilation" and "clock error" Richard Hachel <rh@tiscali.fr> - 2025-08-20 13:51 +0000
Re: About the difference between "time dilation" and "clock error" Python <jp@python.invalid> - 2025-08-20 13:56 +0000
Re: About the difference between "time dilation" and "clock error" Thomas Heger <ttt_heg@web.de> - 2025-08-21 08:31 +0200
Re: About the difference between "time dilation" and "clock error" Thomas Heger <ttt_heg@web.de> - 2025-08-20 10:15 +0200
Re: About the difference between "time dilation" and "clock error" "Paul B. Andersen" <relativity@paulba.no> - 2025-08-20 19:00 +0200
Re: About the difference between "time dilation" and "clock error" Thomas Heger <ttt_heg@web.de> - 2025-08-21 08:39 +0200
Re: About the difference between "time dilation" and "clock error" Python <jp@python.invalid> - 2025-08-21 11:48 +0000
Re: About the difference between "time dilation" and "clock error" Thomas Heger <ttt_heg@web.de> - 2025-08-22 08:20 +0200
Re: About the difference between "time dilation" and "clock error" Python <jp@python.invalid> - 2025-08-22 17:07 +0000
Re: About the difference between "time dilation" and "clock error" Thomas Heger <ttt_heg@web.de> - 2025-08-23 09:22 +0200
Re: About the difference between "time dilation" and "clock error" Python <jp@python.invalid> - 2025-08-21 13:37 +0000
Re: About the difference between "time dilation" and "clock error" Richard Hachel <rh@tiscali.fr> - 2025-08-21 14:57 +0000
Re: About the difference between "time dilation" and "clock error" Thomas Heger <ttt_heg@web.de> - 2025-08-22 08:26 +0200
Re: About the difference between "time dilation" and "clock error" Python <jp@python.invalid> - 2025-08-22 16:53 +0000
Re: About the difference between "time dilation" and "clock error" Thomas Heger <ttt_heg@web.de> - 2025-08-23 09:02 +0200
Re: About the difference between "time dilation" and "clock error" "Paul.B.Andersen" <relativity@paulba.no> - 2025-08-21 21:11 +0200
Re: About the difference between "time dilation" and "clock error" Samsath Bakalov <msml@svalsa.ru> - 2025-08-21 19:32 +0000
Re: About the difference between "time dilation" and "clock error" Richard Hachel <rh@tiscali.fr> - 2025-08-21 21:40 +0000
Re: About the difference between "time dilation" and "clock error" Richard Hachel <rh@tiscali.fr> - 2025-08-21 21:37 +0000
Re: About the difference between "time dilation" and "clock error" Thomas Heger <ttt_heg@web.de> - 2025-08-22 08:43 +0200
Re: About the difference between "time dilation" and "clock error" "Paul.B.Andersen" <relativity@paulba.no> - 2025-08-22 19:59 +0200
Re: About the difference between "time dilation" and "clock error" Thomas Heger <ttt_heg@web.de> - 2025-08-24 08:05 +0200
Re: About the difference between "time dilation" and "clock error" "Paul B. Andersen" <relativity@paulba.no> - 2025-08-24 22:49 +0200
Re: About the difference between "time dilation" and "clock error" Thomas Heger <ttt_heg@web.de> - 2025-08-25 08:26 +0200
Re: About the difference between "time dilation" and "clock error" Python <jp@python.invalid> - 2025-08-25 11:41 +0000
Re: About the difference between "time dilation" and "clock error" Maciej Woźniak <mlwozniak@wp.pl> - 2025-08-25 14:43 +0200
Re: About the difference between "time dilation" and "clock error" Thomas Heger <ttt_heg@web.de> - 2025-08-26 09:55 +0200
Re: About the difference between "time dilation" and "clock error" The Starmaker <starmaker@ix.netcom.com> - 2025-08-26 10:43 -0700
Re: About the difference between "time dilation" and "clock error" Thomas Heger <ttt_heg@web.de> - 2025-08-27 10:33 +0200
Re: About the difference between "time dilation" and "clock error" Khalil Yablochkov <cvb@laoi.ru> - 2025-08-26 20:33 +0000
Re: About the difference between "time dilation" and "clock error" Python <jp@python.invalid> - 2025-08-26 22:39 +0000
Re: About the difference between "time dilation" and "clock error" Maciej Woźniak <mlwozniak@wp.pl> - 2025-08-27 06:33 +0200
Re: About the difference between "time dilation" and "clock error" Thomas Heger <ttt_heg@web.de> - 2025-08-27 10:47 +0200
Re: About the difference between "time dilation" and "clock error" "Paul.B.Andersen" <relativity@paulba.no> - 2025-08-27 12:33 +0200
Re: About the difference between "time dilation" and "clock error" The Starmaker <starmaker@ix.netcom.com> - 2025-08-27 09:35 -0700
Re: About the difference between "time dilation" and "clock error" Thomas Heger <ttt_heg@web.de> - 2025-08-28 09:47 +0200
Re: About the difference between "time dilation" and "clock error" The Starmaker <starmaker@ix.netcom.com> - 2025-08-28 21:38 -0700
Re: About the difference between "time dilation" and "clock error" Thomas Heger <ttt_heg@web.de> - 2025-08-29 09:40 +0200
Re: About the difference between "time dilation" and "clock error" Athel Cornish-Bowden <me@yahoo.com> - 2025-08-29 10:22 +0200
Re: About the difference between "time dilation" and "clock error" The Starmaker <starmaker@ix.netcom.com> - 2025-08-29 07:29 -0700
Re: About the difference between "time dilation" and "clock error" Thomas Heger <ttt_heg@web.de> - 2025-08-30 09:33 +0200
Re: About the difference between "time dilation" and "clock error" The Starmaker <starmaker@ix.netcom.com> - 2025-08-30 10:35 -0700
Re: About the difference between "time dilation" and "clock error" Python <jp@python.invalid> - 2025-08-27 20:27 +0000
Re: About the difference between "time dilation" and "clock error" Thomas Heger <ttt_heg@web.de> - 2025-08-28 10:05 +0200
Re: About the difference between "time dilation" and "clock error" Python <jp@python.invalid> - 2025-08-28 09:47 +0000
Re: About the difference between "time dilation" and "clock error" Maciej Woźniak <mlwozniak@wp.pl> - 2025-08-28 12:09 +0200
Re: About the difference between "time dilation" and "clock error" Richard Hachel <rh@tiscali.fr> - 2025-08-28 14:57 +0000
Re: About the difference between "time dilation" and "clock error" Thomas Heger <ttt_heg@web.de> - 2025-08-29 09:36 +0200
Re: About the difference between "time dilation" and "clock error" Richard Hachel <rh@tiscali.fr> - 2025-08-29 12:00 +0000
Re: About the difference between "time dilation" and "clock error" The Starmaker <starmaker@ix.netcom.com> - 2025-08-29 07:42 -0700
Re: About the difference between "time dilation" and "clock error" Thomas Heger <ttt_heg@web.de> - 2025-08-30 09:32 +0200
Re: About the difference between "time dilation" and "clock error" Richard Hachel <rh@tiscali.fr> - 2025-08-30 13:33 +0000
Re: About the difference between "time dilation" and "clock error" Thomas Heger <ttt_heg@web.de> - 2025-08-31 09:53 +0200
Re: About the difference between "time dilation" and "clock error" Richard Hachel <rh@tiscali.fr> - 2025-08-31 10:36 +0000
Re: About the difference between "time dilation" and "clock error" Thomas Heger <ttt_heg@web.de> - 2025-08-29 09:19 +0200
Re: About the difference between "time dilation" and "clock error" Python <jp@python.invalid> - 2025-08-29 10:00 +0000
Re: About the difference between "time dilation" and "clock error" Thomas Heger <ttt_heg@web.de> - 2025-08-29 12:24 +0200
Re: About the difference between "time dilation" and "clock error" Python <jp@python.invalid> - 2025-08-29 10:33 +0000
Re: About the difference between "time dilation" and "clock error" Maciej Woźniak <mlwozniak@wp.pl> - 2025-08-29 13:50 +0200
Re: About the difference between "time dilation" and "clock error" Thomas Heger <ttt_heg@web.de> - 2025-08-30 09:02 +0200
Re: About the difference between "time dilation" and "clock error" Python <jp@python.invalid> - 2025-08-30 09:53 +0000
Re: About the difference between "time dilation" and "clock error" Slobodan Miheenkov <so@kobn.ru> - 2025-08-30 10:23 +0000
Re: About the difference between "time dilation" and "clock error" Thomas Heger <ttt_heg@web.de> - 2025-08-31 09:13 +0200
Re: About the difference between "time dilation" and "clock error" Python <jp@python.invalid> - 2025-08-31 11:50 +0000
Re: About the difference between "time dilation" and "clock error" Thomas Heger <ttt_heg@web.de> - 2025-09-01 08:27 +0200
Re: About the difference between "time dilation" and "clock error" Maciej Woźniak <mlwozniak@wp.pl> - 2025-09-01 08:31 +0200
Re: About the difference between "time dilation" and "clock error" Thomas Heger <ttt_heg@web.de> - 2025-09-02 08:42 +0200
Re: About the difference between "time dilation" and "clock error" Python <jp@python.invalid> - 2025-09-02 09:40 +0000
Re: About the difference between "time dilation" and "clock error" Python <jp@python.invalid> - 2025-09-02 09:39 +0000
Re: About the difference between "time dilation" and "clock error" Python <jp@python.invalid> - 2025-09-02 10:28 +0000
Re: About the difference between "time dilation" and "clock error" Antone De la fontaine <tle@aandot.fr> - 2025-09-02 19:56 +0000
Re: About the difference between "time dilation" and "clock error" Python <jp@python.invalid> - 2025-09-04 15:40 +0000
Re: About the difference between "time dilation" and "clock error" Python <jp@python.invalid> - 2025-08-30 10:44 +0000
Re: About the difference between "time dilation" and "clock error" Thomas Heger <ttt_heg@web.de> - 2025-08-31 09:28 +0200
Re: About the difference between "time dilation" and "clock error" Richard Hachel <rh@tiscali.fr> - 2025-08-29 11:38 +0000
Re: About the difference between "time dilation" and "clock error" Thomas Heger <ttt_heg@web.de> - 2025-08-30 09:12 +0200
Re: About the difference between "time dilation" and "clock error" Richard Hachel <rh@tiscali.fr> - 2025-08-30 12:46 +0000
Re: About the difference between "time dilation" and "clock error" Thomas Heger <ttt_heg@web.de> - 2025-08-31 09:35 +0200
Re: About the difference between "time dilation" and "clock error" Richard Hachel <rh@tiscali.fr> - 2025-08-30 13:11 +0000
Re: About the difference between "time dilation" and "clock error" Python <jp@python.invalid> - 2025-08-30 13:19 +0000
Re: About the difference between "time dilation" and "clock error" Maciej Woźniak <mlwozniak@wp.pl> - 2025-08-30 15:40 +0200
Re: About the difference between "time dilation" and "clock error" Richard Hachel <rh@tiscali.fr> - 2025-08-30 13:44 +0000
Re: About the difference between "time dilation" and "clock error" Richard Hachel <rh@tiscali.fr> - 2025-08-28 14:47 +0000
Re: About the difference between "time dilation" and "clock error" "Paul B. Andersen" <relativity@paulba.no> - 2025-08-25 22:22 +0200
Re: About the difference between "time dilation" and "clock error" Chayne Prokurorov <nhp@ruurkrr.ru> - 2025-08-20 19:14 +0000
Re: About the difference between "time dilation" and "clock error" Richard Hachel <rh@tiscali.fr> - 2025-08-19 02:41 +0000
Re: About the difference between "time dilation" and "clock error" Richard Hachel <rh@tiscali.fr> - 2025-08-19 02:46 +0000
Re: About the difference between "time dilation" and "clock error" Thomas Heger <ttt_heg@web.de> - 2025-07-30 19:25 +0200
Re: About the difference between "time dilation" and "clock error" "Paul.B.Andersen" <relativity@paulba.no> - 2025-07-31 21:59 +0200
Re: About the difference between "time dilation" and "clock error" Python <jp@python.invalid> - 2025-08-01 16:50 +0000
Re: About the difference between "time dilation" and "clock error" Python <jp@python.invalid> - 2025-08-01 16:51 +0000
Re: About the difference between "time dilation" and "clock error" Richard Hachel <rh@tiscali.fr> - 2025-08-01 19:25 +0000
Re: About the difference between "time dilation" and "clock error" Python <jp@python.invalid> - 2025-08-01 19:39 +0000
Re: About the difference between "time dilation" and "clock error" Python <jp@python.invalid> - 2025-08-01 19:52 +0000
Page 10 of 11 — ← Prev page 1 … 8 9 [10] 11 Next page →
| From | Python <jp@python.invalid> |
|---|---|
| Date | 2025-08-31 11:50 +0000 |
| Message-ID | <R9CGpBBmqXJWqbzFlOOUgDRNSWw@jntp> |
| In reply to | #665706 |
Le 31/08/2025 à 09:09, Thomas Heger a écrit : > Am Samstag000030, 30.08.2025 um 11:53 schrieb Python: > ... >>>>> >>>>> To transfer a timing signal from point A to point B would require, >>>>> to measure the delay of the signal, once it will arrive at the >>>>> remote side. >>>> >>>> No. Everything will be computed later using *values* of t_A, t'_A and >>>> t_B. >>>> >>>> What A need is the *value* t_B observed by B. >>> >>> But HOW should B send this value to A? >> >> It doesn't matter. I told you: pigeon, e-mail, mail, sound, written on >> piece of paper and thrown out. This is not a problem. >> > > Ok, you receive a letter from the Moon, saying 'we have now 13:00:00 > Moon mean time'. This is NOT what t_B is. You pretend to have read the article, but you show at every single post that you've forgotten its content.
[toc] | [prev] | [next] | [standalone]
| From | Thomas Heger <ttt_heg@web.de> |
|---|---|
| Date | 2025-09-01 08:27 +0200 |
| Message-ID | <mhksfgFc6t3U2@mid.individual.net> |
| In reply to | #665713 |
Am Sonntag000031, 31.08.2025 um 13:50 schrieb Python: > Le 31/08/2025 à 09:09, Thomas Heger a écrit : >> Am Samstag000030, 30.08.2025 um 11:53 schrieb Python: >> ... >>>>>> >>>>>> To transfer a timing signal from point A to point B would require, >>>>>> to measure the delay of the signal, once it will arrive at the >>>>>> remote side. >>>>> >>>>> No. Everything will be computed later using *values* of t_A, t'_A >>>>> and t_B. >>>>> >>>>> What A need is the *value* t_B observed by B. >>>> >>>> But HOW should B send this value to A? >>> >>> It doesn't matter. I told you: pigeon, e-mail, mail, sound, written >>> on piece of paper and thrown out. This is not a problem. >>> >> >> Ok, you receive a letter from the Moon, saying 'we have now 13:00:00 >> Moon mean time'. > > This is NOT what t_B is. You pretend to have read the article, but you > show at every single post that you've forgotten its content. > I have used this setting: station 'A' is located in Houston, Texas and station 'B' upon the Moon. A-time is usual Texas-time and 'B-time' was named 'Moon mean time'. Now we have a huge clock on the Moon and also an 'Apollo' crew to maintain the clock there. You wrote, that a number of methods would be possible by which Houston could be informed about t_B, which included also letters sent by mail. And I have written, that you should explain to me, what a letter with the time 'it's now 13:00:00 Moon mean time' arriving one week later would say. But you are in fact correct and t_B was defined as time of arrival of the signal in B, which was the meaning of t_B. Therefore the letter from the Moon should contain the message ' your signal arrived here at 13:00:00 Moon mean time'. Now: how do you synchronize the clock on the Moon with that information? TH TH
[toc] | [prev] | [next] | [standalone]
| From | Maciej Woźniak <mlwozniak@wp.pl> |
|---|---|
| Date | 2025-09-01 08:31 +0200 |
| Message-ID | <186114e3360ef182$808280$2382441$c2065a8b@news.newsdemon.com> |
| In reply to | #665744 |
On 9/1/2025 8:27 AM, Thomas Heger wrote: > Am Sonntag000031, 31.08.2025 um 13:50 schrieb Python: >> Le 31/08/2025 à 09:09, Thomas Heger a écrit : >>> Am Samstag000030, 30.08.2025 um 11:53 schrieb Python: >>> ... >>>>>>> >>>>>>> To transfer a timing signal from point A to point B would >>>>>>> require, to measure the delay of the signal, once it will arrive >>>>>>> at the remote side. >>>>>> >>>>>> No. Everything will be computed later using *values* of t_A, t'_A >>>>>> and t_B. >>>>>> >>>>>> What A need is the *value* t_B observed by B. >>>>> >>>>> But HOW should B send this value to A? >>>> >>>> It doesn't matter. I told you: pigeon, e-mail, mail, sound, written >>>> on piece of paper and thrown out. This is not a problem. >>>> >>> >>> Ok, you receive a letter from the Moon, saying 'we have now 13:00:00 >>> Moon mean time'. >> >> This is NOT what t_B is. You pretend to have read the article, but you >> show at every single post that you've forgotten its content. >> > I have used this setting: > > station 'A' is located in Houston, Texas and station 'B' upon the Moon. > > A-time is usual Texas-time and 'B-time' was named 'Moon mean time'. > > Now we have a huge clock on the Moon and also an 'Apollo' crew to > maintain the clock there. > > You wrote, that a number of methods would be possible by which Houston > could be informed about t_B, which included also letters sent by mail. > > And I have written, that you should explain to me, what a letter with > the time 'it's now 13:00:00 Moon mean time' arriving one week later > would say. > > But you are in fact correct and t_B was defined as time of arrival of > the signal in B, which was the meaning of t_B. > > Therefore the letter from the Moon should contain the message ' your > signal arrived here at 13:00:00 Moon mean time'. > > Now: how do you synchronize the clock on the Moon with that information? He doesn't. His Holiest Procedure can't manage this case, it's outside its ridiculous requirements. The procedure works magnificiently, but only in gedankenwelt.
[toc] | [prev] | [next] | [standalone]
| From | Thomas Heger <ttt_heg@web.de> |
|---|---|
| Date | 2025-09-02 08:42 +0200 |
| Message-ID | <mhnhmmFq294U1@mid.individual.net> |
| In reply to | #665745 |
Am Montag000001, 01.09.2025 um 08:31 schrieb Maciej Woźniak: > On 9/1/2025 8:27 AM, Thomas Heger wrote: >> Am Sonntag000031, 31.08.2025 um 13:50 schrieb Python: >>> Le 31/08/2025 à 09:09, Thomas Heger a écrit : >>>> Am Samstag000030, 30.08.2025 um 11:53 schrieb Python: >>>> ... >>>>>>>> >>>>>>>> To transfer a timing signal from point A to point B would >>>>>>>> require, to measure the delay of the signal, once it will arrive >>>>>>>> at the remote side. >>>>>>> >>>>>>> No. Everything will be computed later using *values* of t_A, t'_A >>>>>>> and t_B. >>>>>>> >>>>>>> What A need is the *value* t_B observed by B. >>>>>> >>>>>> But HOW should B send this value to A? >>>>> >>>>> It doesn't matter. I told you: pigeon, e-mail, mail, sound, written >>>>> on piece of paper and thrown out. This is not a problem. >>>>> >>>> >>>> Ok, you receive a letter from the Moon, saying 'we have now 13:00:00 >>>> Moon mean time'. >>> >>> This is NOT what t_B is. You pretend to have read the article, but >>> you show at every single post that you've forgotten its content. >>> >> I have used this setting: >> >> station 'A' is located in Houston, Texas and station 'B' upon the Moon. >> >> A-time is usual Texas-time and 'B-time' was named 'Moon mean time'. >> >> Now we have a huge clock on the Moon and also an 'Apollo' crew to >> maintain the clock there. >> >> You wrote, that a number of methods would be possible by which Houston >> could be informed about t_B, which included also letters sent by mail. >> >> And I have written, that you should explain to me, what a letter with >> the time 'it's now 13:00:00 Moon mean time' arriving one week later >> would say. >> >> But you are in fact correct and t_B was defined as time of arrival of >> the signal in B, which was the meaning of t_B. >> >> Therefore the letter from the Moon should contain the message ' your >> signal arrived here at 13:00:00 Moon mean time'. >> >> Now: how do you synchronize the clock on the Moon with that information? > > He doesn't. His Holiest Procedure can't manage > this case, it's outside its ridiculous > requirements. The procedure works magnificiently, > but only in gedankenwelt. > The problem is much more serious than this example suggests. In fact, the delay-problem isn't correctly taken into consideration in most of usual cosmology. 'Usual cosmology' takes the picture we see in the night sky as 'universe' and treats that, as if it would be a valid representation of the real universe. But: what we actually see in the night sky is 'layered in time', because further away means also longer ago. Now it wouldn't make sense to assume, that a foreground object would interact with an object in the background, because that background object belongs to a different time than the foreground object. This 'little' problem gets usually ignored. So, what cosmologists actually do is nonsense and the model they develop are therefore nonsense, too. To treat this problem properly would require, as first measure, to correct SRT. But that is simply not allowed (because of the saint like status of Einstein). So physics get stuck in a dilemma, because what should be done cannot be done. TH
[toc] | [prev] | [next] | [standalone]
| From | Python <jp@python.invalid> |
|---|---|
| Date | 2025-09-02 09:40 +0000 |
| Message-ID | <tsYtpKvb3ZlKnlXCAOqSqzxC4SY@jntp> |
| In reply to | #665752 |
Le 02/09/2025 à 08:38, Thomas Heger a écrit : .. > 'Usual cosmology' takes the picture we see in the night sky as > 'universe' and treats that, as if it would be a valid representation of > the real universe. Are you sure of that? Did you check by reading actual papers in cosmology?
[toc] | [prev] | [next] | [standalone]
| From | Python <jp@python.invalid> |
|---|---|
| Date | 2025-09-02 09:39 +0000 |
| Message-ID | <0fdVHqw6n8F_K4zVywxLvMW_-n0@jntp> |
| In reply to | #665744 |
Le 01/09/2025 à 08:23, Thomas Heger a écrit : .. > station 'A' is located in Houston, Texas and station 'B' upon the Moon. > > A-time is usual Texas-time and 'B-time' was named 'Moon mean time'. > > Now we have a huge clock on the Moon and also an 'Apollo' crew to > maintain the clock there. No reason for this clock to be huge. > You wrote, that a number of methods would be possible by which Houston > could be informed about t_B, which included also letters sent by mail. > > And I have written, that you should explain to me, what a letter with > the time 'it's now 13:00:00 Moon mean time' arriving one week later > would say. > > But you are in fact correct and t_B was defined as time of arrival of > the signal in B, which was the meaning of t_B. > > Therefore the letter from the Moon should contain the message ' your > signal arrived here at 13:00:00 Moon mean time'. > > Now: how do you synchronize the clock on the Moon with that information? The message is sent to A in your scenario, so it is the clock on Earth that could be synchronized, by applying a computed offset, with clock B. In order to do so A also need to uses t_A and t'_A. As both are values that have been read on clock A before, there is no communication issues here. Right? Let's suppose that these values are: t_A = 12:30:00 t'_A = 11:30:2.56444 t_B = 13:00:00 A few questions now: 1. Can you check if 2*d/(tpA - tA) = c [d is the Earth-Moon distance] ? 2. Can you check if t_B - t_A = t'_A - t_B ? What does this means in term of clocks synchronization according to Einstein? 3. Can you compute an offset to be applied to clock A so that clocks A & B will be, then, synchronized?
[toc] | [prev] | [next] | [standalone]
| From | Python <jp@python.invalid> |
|---|---|
| Date | 2025-09-02 10:28 +0000 |
| Message-ID | <8KHMXSz4az4OqWEuGVIdPGfh4xE@jntp> |
| In reply to | #665754 |
Le 02/09/2025 à 11:39, Python a écrit : > Le 01/09/2025 à 08:23, Thomas Heger a écrit : > ... >> station 'A' is located in Houston, Texas and station 'B' upon the Moon. >> >> A-time is usual Texas-time and 'B-time' was named 'Moon mean time'. >> >> Now we have a huge clock on the Moon and also an 'Apollo' crew to >> maintain the clock there. > > No reason for this clock to be huge. > >> You wrote, that a number of methods would be possible by which Houston >> could be informed about t_B, which included also letters sent by mail. >> >> And I have written, that you should explain to me, what a letter with >> the time 'it's now 13:00:00 Moon mean time' arriving one week later >> would say. >> >> But you are in fact correct and t_B was defined as time of arrival of >> the signal in B, which was the meaning of t_B. >> >> Therefore the letter from the Moon should contain the message ' your >> signal arrived here at 13:00:00 Moon mean time'. >> >> Now: how do you synchronize the clock on the Moon with that information? > > The message is sent to A in your scenario, so it is the clock on Earth that > could be synchronized, by applying a computed offset, with clock B. > > In order to do so A also need to uses t_A and t'_A. As both are values that have > been read on clock A before, there is no communication issues here. Right? > > Let's suppose that these values are: > > t_A = 12:30:00 > t'_A = 11:30:2.56444 Typo: t_A = 12:30:00 t'_A = 12:30:2.56444 > t_B = 13:00:00 > > A few questions now: > 1. Can you check if 2*d/(tpA - tA) = c [d is the Earth-Moon distance] ? > 2. Can you check if t_B - t_A = t'_A - t_B ? What does this means in term of > clocks synchronization according to Einstein? > 3. Can you compute an offset to be applied to clock A so that clocks A & B will > be, then, synchronized?
[toc] | [prev] | [next] | [standalone]
| From | Antone De la fontaine <tle@aandot.fr> |
|---|---|
| Date | 2025-09-02 19:56 +0000 |
| Message-ID | <1097i57$npqr$1@dont-email.me> |
| In reply to | #665756 |
Python wrote: >> In order to do so A also need to uses t_A and t'_A. As both are values >> that have been read on clock A before, there is no communication issues >> here. Right? >> >> Let's suppose that these values are: >> >> t_A = 12:30:00 t'_A = 11:30:2.56444 > > Typo: t_A = 12:30:00 t'_A = 12:30:2.56444 quit posting now, you’ve earned enough for a Big Mack already, fucking imbecile.
[toc] | [prev] | [next] | [standalone]
| From | Python <jp@python.invalid> |
|---|---|
| Date | 2025-09-04 15:40 +0000 |
| Message-ID | <cooo0eXFVWGKbIf3yLeEG6zRwrY@jntp> |
| In reply to | #665756 |
Le 02/09/2025 à 12:28, Python a écrit : > Le 02/09/2025 à 11:39, Python a écrit : >> Le 01/09/2025 à 08:23, Thomas Heger a écrit : >> ... >>> station 'A' is located in Houston, Texas and station 'B' upon the Moon. >>> >>> A-time is usual Texas-time and 'B-time' was named 'Moon mean time'. >>> >>> Now we have a huge clock on the Moon and also an 'Apollo' crew to >>> maintain the clock there. >> >> No reason for this clock to be huge. >> >>> You wrote, that a number of methods would be possible by which Houston >>> could be informed about t_B, which included also letters sent by mail. >>> >>> And I have written, that you should explain to me, what a letter with >>> the time 'it's now 13:00:00 Moon mean time' arriving one week later >>> would say. >>> >>> But you are in fact correct and t_B was defined as time of arrival of >>> the signal in B, which was the meaning of t_B. >>> >>> Therefore the letter from the Moon should contain the message ' your >>> signal arrived here at 13:00:00 Moon mean time'. >>> >>> Now: how do you synchronize the clock on the Moon with that information? >> >> The message is sent to A in your scenario, so it is the clock on Earth that >> could be synchronized, by applying a computed offset, with clock B. >> >> In order to do so A also need to uses t_A and t'_A. As both are values that have >> been read on clock A before, there is no communication issues here. Right? >> >> Let's suppose that these values are: >> >> t_A = 12:30:00 >> t'_A = 11:30:2.56444 > > Typo: > t_A = 12:30:00 > t'_A = 12:30:2.56444 > > >> t_B = 13:00:00 >> >> A few questions now: >> 1. Can you check if 2*d/(tpA - tA) = c [d is the Earth-Moon distance] ? >> 2. Can you check if t_B - t_A = t'_A - t_B ? What does this means in term of >> clocks synchronization according to Einstein? >> 3. Can you compute an offset to be applied to clock A so that clocks A & B will >> be, then, synchronized? No answer? How weird...
[toc] | [prev] | [next] | [standalone]
| From | Python <jp@python.invalid> |
|---|---|
| Date | 2025-08-30 10:44 +0000 |
| Message-ID | <bQ86VFRLjFrpUNOC--TQmuYPFxg@jntp> |
| In reply to | #665678 |
Le 30/08/2025 à 08:58, Thomas Heger a écrit : .. > Another possibility: the crew of Apollo 12 reads the clock on the Moon, > writes the value '13:00:00' on a sheet of paper and take that home to > Houston, Texas, where they read it roughly one week later. It would work very well. You seem to have forgotten what t_A, t_B and t'_A ARE. They have been read before in a very well defined procedure described in Einstein's paper. It could have been days before the astronauts' return. It doesn't matter. To have to wait a week before having clock A synchronized with clock B is not a problem.
[toc] | [prev] | [next] | [standalone]
| From | Thomas Heger <ttt_heg@web.de> |
|---|---|
| Date | 2025-08-31 09:28 +0200 |
| Message-ID | <mhibleFtki9U3@mid.individual.net> |
| In reply to | #665687 |
Am Samstag000030, 30.08.2025 um 12:44 schrieb Python: > Le 30/08/2025 à 08:58, Thomas Heger a écrit : > .. >> Another possibility: the crew of Apollo 12 reads the clock on the >> Moon, writes the value '13:00:00' on a sheet of paper and take that >> home to Houston, Texas, where they read it roughly one week later. > > It would work very well. > > You seem to have forgotten what t_A, t_B and t'_A ARE. They have been > read before in a very well defined procedure described in Einstein's > paper. It could have been days before the astronauts' return. It doesn't > matter. > > To have to wait a week before having clock A synchronized with clock B > is not a problem. > > You failed to describe a method, by which the remote clock could be synchronized. This method is obviously necessary, because it was the aim to synchronize clocks. I had actually written about a possible method, which worked like this: clock B shall be synchronized with clock A. A sends a 'ping' to the remote station, measures the delay of the returned signal, cuts the time in half and regards that value as delay, which is expected in a communication between A and B. Now A sends the own time value plus that delay to B, encoded in some kind of message, which B can decipher. B reads that message, decodes the time value and sets the own clock to that value. Now both clocks are in synch. (There are a few conditions, however, which are usually not mentioned. Mainly A and B should not move in respect to each other and the speed of the signal should be equal on both ways). But you seemingly didn't like this method and Einstein didn't use it, anyhow. So: what else do you want? That the transit time for both directions is equal, for instance, would not synchronize anything, because the part is missing, which could eventually adjust a clock to some new values. So: how do you want to do that??? TH
[toc] | [prev] | [next] | [standalone]
| From | Richard Hachel <rh@tiscali.fr> |
|---|---|
| Date | 2025-08-29 11:38 +0000 |
| Message-ID | <NGednlow1i1Xc4NbOFRh0IUaAPs@jntp> |
| In reply to | #665664 |
Le 29/08/2025 à 12:20, Thomas Heger a écrit : > > To transfer a timing signal from point A to point B would require, to > measure the delay of the signal, once it will arrive at the remote side. > > This could be done by pigeons, if you like that, but would require to > know the delay in advance, too. > > Otherwise you cannot tell the remote station, to what time you want them > to turn their clock. But that's absurd. In relativity, you're no longer in a classical framework. The notion of absolute simultaneity no longer exists between A and B. I'm amazed that, after forty years of saying this, no one can truly understand this simple fact that an 11-year-old child should understand. If you set your watch A to B, assuming spatial isochrony, that is, an absolute present-time plane between the two, you assume that the watches are in tune if, at the instant B receives the forward signal, it reads tB=AB/c. In both cases (Newton or Poincaré), for A, the watches will be in tune. But only for A. For B, in Newtonian isochronic mode, B will also be in tune with A. But in relativistic mode, and it is the theory of relativity that is true, B will no longer be in tune with A, and the offset for B will become dt=2AB/c. I'm surprised no one makes the effort to understand this. Yet it's both very simple and very obvious if you consider that the notion of absolute present time within a simple inertial frame of reference is probably pure fantasy, a scientific whim based on nothing. R.H.
[toc] | [prev] | [next] | [standalone]
| From | Thomas Heger <ttt_heg@web.de> |
|---|---|
| Date | 2025-08-30 09:12 +0200 |
| Message-ID | <mhfmbsFfnejU5@mid.individual.net> |
| In reply to | #665666 |
Am Freitag000029, 29.08.2025 um 13:38 schrieb Richard Hachel: > Le 29/08/2025 à 12:20, Thomas Heger a écrit : >> >> To transfer a timing signal from point A to point B would require, to >> measure the delay of the signal, once it will arrive at the remote side. >> >> This could be done by pigeons, if you like that, but would require to >> know the delay in advance, too. >> >> Otherwise you cannot tell the remote station, to what time you want >> them to turn their clock. > > But that's absurd. > In relativity, you're no longer in a classical framework. In special relativity, what we are discussing in this moment, this is actually the case, because SRT is without acceleration, curved spacetime and so forth. > The notion of absolute simultaneity no longer exists between A and B. > I'm amazed that, after forty years of saying this, no one can truly > understand this simple fact that an 11-year-old child should understand. > If you set your watch A to B, assuming spatial isochrony, that is, an > absolute present-time plane between the two, you assume that the watches > are in tune if, at the instant B receives the forward signal, it reads > tB=AB/c. > In both cases (Newton or Poincaré), for A, the watches will be in tune. > But only for A. This is what I have written several times now. I wanted to address the problem, that 'synchronization' would need to tune at least one of the two clocks under consideration. The best option would be to tune clock B to 'A-time'. But that isn't symmetric. If we want the process symmetric, we would need to introduce a third time 'C-time', which stems from a place in the middle between A and B. Only this method had several disadvantages. For instanced the method would only work for two points. Another method would use a hypothetical signal, which has no delay and could travel with infinite velocity. This signal would define synchronicity, but could not be used in practice (mainly because it doesn't exist). But we could add the delay 'by hand' and get a convincing story. TH > For B, in Newtonian isochronic mode, B will also be in tune with A. > But in relativistic mode, and it is the theory of relativity that is > true, B will no longer be in tune with A, and the offset for B will > become dt=2AB/c. > > I'm surprised no one makes the effort to understand this. > > Yet it's both very simple and very obvious if you consider that the > notion of absolute present time within a simple inertial frame of > reference is probably pure fantasy, a scientific whim based on nothing. > > R.H.
[toc] | [prev] | [next] | [standalone]
| From | Richard Hachel <rh@tiscali.fr> |
|---|---|
| Date | 2025-08-30 12:46 +0000 |
| Message-ID | <wW3KkRAl_Uet3JR4j6qtC5PGzdg@jntp> |
| In reply to | #665679 |
Le 30/08/2025 à 09:08, Thomas Heger a écrit : > Am Freitag000029, 29.08.2025 um 13:38 schrieb Richard Hachel: > In special relativity, what we are discussing in this moment, this is > actually the case, because SRT is without acceleration, curved spacetime > and so forth. There's a huge misunderstanding among relativists about what the theory of relativity is, and the worst part is that they don't want to hear about a more coherent, simpler theory that can be taught in high school. There's so much nonsense being said. For example, you talk about accelerations; yet, for Hachel, accelerations are always pure special relativity. So we need to review EVERYTHING: right down to the definitions. R.H.
[toc] | [prev] | [next] | [standalone]
| From | Thomas Heger <ttt_heg@web.de> |
|---|---|
| Date | 2025-08-31 09:35 +0200 |
| Message-ID | <mhic2oFtki9U4@mid.individual.net> |
| In reply to | #665692 |
Am Samstag000030, 30.08.2025 um 14:46 schrieb Richard Hachel: > Le 30/08/2025 à 09:08, Thomas Heger a écrit : >> Am Freitag000029, 29.08.2025 um 13:38 schrieb Richard Hachel: > >> In special relativity, what we are discussing in this moment, this is >> actually the case, because SRT is without acceleration, curved >> spacetime and so forth. > > There's a huge misunderstanding among relativists about what the theory > of relativity is, and the worst part is that they don't want to hear > about a more coherent, simpler theory that can be taught in high school. > There's so much nonsense being said. > For example, you talk about accelerations; yet, for Hachel, > accelerations are always pure special relativity. > So we need to review EVERYTHING: right down to the definitions. > We are talking about different things: I wanted to address the article 'On the electrodynamics of moving bodies' and what it actually says, while you want to correct 'relativity per se'. But it isn't my aim to correct Einstein's paper. I have counted hundreds of errors in that particular paper and try to defend my claims, that these are all real errors (what Python et al deny). How relativity should really be, that wasn't my topic, even if it should certainly be different than what Einstein had written. TH
[toc] | [prev] | [next] | [standalone]
| From | Richard Hachel <rh@tiscali.fr> |
|---|---|
| Date | 2025-08-30 13:11 +0000 |
| Message-ID | <o7vlRr3tcSuMHaZdPciuFTng1aE@jntp> |
| In reply to | #665679 |
Le 30/08/2025 à 09:08, Thomas Heger a écrit : > Am Freitag000029, 29.08.2025 um 13:38 schrieb Richard Hachel: >> Le 29/08/2025 à 12:20, Thomas Heger a écrit : >>> >>> To transfer a timing signal from point A to point B would require, to >>> measure the delay of the signal, once it will arrive at the remote side. >>> >>> This could be done by pigeons, if you like that, but would require to >>> know the delay in advance, too. >>> >>> Otherwise you cannot tell the remote station, to what time you want >>> them to turn their clock. >> >> But that's absurd. >> In relativity, you're no longer in a classical framework. > > In special relativity, what we are discussing in this moment, this is > actually the case, because SRT is without acceleration, curved spacetime > and so forth. > >> The notion of absolute simultaneity no longer exists between A and B. >> I'm amazed that, after forty years of saying this, no one can truly >> understand this simple fact that an 11-year-old child should understand. >> If you set your watch A to B, assuming spatial isochrony, that is, an >> absolute present-time plane between the two, you assume that the watches >> are in tune if, at the instant B receives the forward signal, it reads >> tB=AB/c. >> In both cases (Newton or Poincaré), for A, the watches will be in tune. >> But only for A. > > This is what I have written several times now. > > I wanted to address the problem, that 'synchronization' would need to > tune at least one of the two clocks under consideration. > > The best option would be to tune clock B to 'A-time'. > > But that isn't symmetric. > > If we want the process symmetric, we would need to introduce a third > time 'C-time', which stems from a place in the middle between A and B. > > Only this method had several disadvantages. > > For instanced the method would only work for two points. > > Another method would use a hypothetical signal, which has no delay and > could travel with infinite velocity. > > This signal would define synchronicity, but could not be used in > practice (mainly because it doesn't exist). > > But we could add the delay 'by hand' and get a convincing story. > > THI've already answered all of this, but unfortunately, no one is listening. It is IMPOSSIBLE to synchronize two watches placed in two different locations. Romeo placed on a park bench, and Juliet placed on that other bench, thirty meters away, will NEVER, BY THE NATURE OF THINGS, be able to synchronize their watches absolutely, that is, reciprocally. If Romeo, by some means, sets Juliet's watch to his own, Juliet will observe an even greater imbalance dt=2AB/c, and vice versa. Now, it is possible to synchronize oneself to a watch, that is, to its own present-time hyperplane, to its own universe simultaneity. Only, it is essential that this watch be equidistant from all the other watches in the universe, which is technically absurd. So we'll imagine a fourth dimension orthogonal to the other three, and place there, ideally at infinity, a virtual clock, which will be equidistant from all points in our 3D universe. And we'll assume that its hyperplane will be the reference for events in the universe. We can then date events based on something. Otherwise, we wouldn't be able to do anything. It would even be completely impossible to say whether the Titanic (April 14, 1912) sank BEFORE or AFTER the Supernova-1987 explosion, since it depends on the observer's POSITION. R.H.
[toc] | [prev] | [next] | [standalone]
| From | Python <jp@python.invalid> |
|---|---|
| Date | 2025-08-30 13:19 +0000 |
| Message-ID | <5fSv7jzygoMZqkPbfCy4D0GboyY@jntp> |
| In reply to | #665696 |
Le 30/08/2025 à 15:11, Richard Hachel a écrit : > Le 30/08/2025 à 09:08, Thomas Heger a écrit : >> Am Freitag000029, 29.08.2025 um 13:38 schrieb Richard Hachel: >>> Le 29/08/2025 à 12:20, Thomas Heger a écrit : >>>> >>>> To transfer a timing signal from point A to point B would require, to >>>> measure the delay of the signal, once it will arrive at the remote side. >>>> >>>> This could be done by pigeons, if you like that, but would require to >>>> know the delay in advance, too. >>>> >>>> Otherwise you cannot tell the remote station, to what time you want >>>> them to turn their clock. >>> >>> But that's absurd. >>> In relativity, you're no longer in a classical framework. >> >> In special relativity, what we are discussing in this moment, this is >> actually the case, because SRT is without acceleration, curved spacetime >> and so forth. >> >>> The notion of absolute simultaneity no longer exists between A and B. >>> I'm amazed that, after forty years of saying this, no one can truly >>> understand this simple fact that an 11-year-old child should understand. >>> If you set your watch A to B, assuming spatial isochrony, that is, an >>> absolute present-time plane between the two, you assume that the watches >>> are in tune if, at the instant B receives the forward signal, it reads >>> tB=AB/c. >>> In both cases (Newton or Poincaré), for A, the watches will be in tune. >>> But only for A. >> >> This is what I have written several times now. >> >> I wanted to address the problem, that 'synchronization' would need to >> tune at least one of the two clocks under consideration. >> >> The best option would be to tune clock B to 'A-time'. >> >> But that isn't symmetric. >> >> If we want the process symmetric, we would need to introduce a third >> time 'C-time', which stems from a place in the middle between A and B. >> >> Only this method had several disadvantages. >> >> For instanced the method would only work for two points. >> >> Another method would use a hypothetical signal, which has no delay and >> could travel with infinite velocity. >> >> This signal would define synchronicity, but could not be used in >> practice (mainly because it doesn't exist). >> >> But we could add the delay 'by hand' and get a convincing story. >> >> THI've already answered all of this, but unfortunately, no one is listening. > It is IMPOSSIBLE to synchronize two watches placed in two different locations It is impossible with *your* definition of simultaneity i.e. "synchronization". It is possible with Poincaré's definition which matches with Einstein convention. PERIOD.
[toc] | [prev] | [next] | [standalone]
| From | Maciej Woźniak <mlwozniak@wp.pl> |
|---|---|
| Date | 2025-08-30 15:40 +0200 |
| Message-ID | <18608f238bc8b00e$128949$2376393$c2365abb@news.newsdemon.com> |
| In reply to | #665697 |
On 8/30/2025 3:19 PM, Python wrote: > Le 30/08/2025 à 15:11, Richard Hachel a écrit : >> Le 30/08/2025 à 09:08, Thomas Heger a écrit : >>> Am Freitag000029, 29.08.2025 um 13:38 schrieb Richard Hachel: >>>> Le 29/08/2025 à 12:20, Thomas Heger a écrit : >>>>> >>>>> To transfer a timing signal from point A to point B would require, >>>>> to measure the delay of the signal, once it will arrive at the >>>>> remote side. >>>>> >>>>> This could be done by pigeons, if you like that, but would require >>>>> to know the delay in advance, too. >>>>> >>>>> Otherwise you cannot tell the remote station, to what time you want >>>>> them to turn their clock. >>>> >>>> But that's absurd. >>>> In relativity, you're no longer in a classical framework. >>> >>> In special relativity, what we are discussing in this moment, this is >>> actually the case, because SRT is without acceleration, curved >>> spacetime and so forth. >>> >>>> The notion of absolute simultaneity no longer exists between A and B. >>>> I'm amazed that, after forty years of saying this, no one can truly >>>> understand this simple fact that an 11-year-old child should >>>> understand. >>>> If you set your watch A to B, assuming spatial isochrony, that is, >>>> an absolute present-time plane between the two, you assume that the >>>> watches are in tune if, at the instant B receives the forward >>>> signal, it reads tB=AB/c. >>>> In both cases (Newton or Poincaré), for A, the watches will be in >>>> tune. But only for A. >>> >>> This is what I have written several times now. >>> >>> I wanted to address the problem, that 'synchronization' would need to >>> tune at least one of the two clocks under consideration. >>> >>> The best option would be to tune clock B to 'A-time'. >>> >>> But that isn't symmetric. >>> >>> If we want the process symmetric, we would need to introduce a third >>> time 'C-time', which stems from a place in the middle between A and B. >>> >>> Only this method had several disadvantages. >>> >>> For instanced the method would only work for two points. >>> >>> Another method would use a hypothetical signal, which has no delay >>> and could travel with infinite velocity. >>> >>> This signal would define synchronicity, but could not be used in >>> practice (mainly because it doesn't exist). >>> >>> But we could add the delay 'by hand' and get a convincing story. >>> >>> THI've already answered all of this, but unfortunately, no one is >>> listening. >> It is IMPOSSIBLE to synchronize two watches placed in two different >> locations > > It is impossible with *your* definition of simultaneity i.e. > "synchronization". > > It is possible with Poincaré's definition which matches with Einstein > convention. No, it is not. Even your moronic Shit is admitting it is only possible under no gravity, i.e. nowhere.
[toc] | [prev] | [next] | [standalone]
| From | Richard Hachel <rh@tiscali.fr> |
|---|---|
| Date | 2025-08-30 13:44 +0000 |
| Message-ID | <RSEaNIF4gKh5zHQYG-LylIlBNtk@jntp> |
| In reply to | #665697 |
Le 30/08/2025 à 15:19, Python a écrit : > Le 30/08/2025 à 15:11, Richard Hachel a écrit : >> Le 30/08/2025 à 09:08, Thomas Heger a écrit : >> It is IMPOSSIBLE to synchronize two watches placed in two different locations > > It is impossible with *your* definition of simultaneity C'est ce que je dis. Le problème n'est donc plus : "ce qu'il dit est-il cohérent?" Mais : "qui a raison?" > It is possible with Poincaré's definition which matches with Einstein > convention. C'est cohérent en mode isochrone, c'est à dire si l'on a cette croyance féroce en un plan du temps présent commun à tous les observateurs présent dans le même référentiel (je crois que Thomas Hager, finalement, n'a rien compris de ce que je lui dis). En mode Hachel, la cohérence est ailleurs. J'ai longtemps pensé qu'il faudrait encore attendre quelques années, voire décennies, pour que la science puisse prouver que c'est Hachel qui a raison et pas les physiciens mondiaux (à un contre des millions, il fallait avoir de la force), et que l'on puisse montrer que l'hyperplan de temps présent dans UN référentiel donné, est une construction abstraite et non naturelle, bien que nos croyance y tiennent fermement. Sauf que même pas besoin. Le diable ne fait pas crédit : on peut payer tout de suite. Si tu étudies de façon profonde un voyageur de Langevin, tu te rends compte que le paradoxe ressort de l'autre côté du tapis, lors de la description par l'effet Doppler (notion de vitesses apparentes). L'absurdité ressort, monstrueuse, et tout s'écroule si tu ne prends pas correctement toutes les notions que j'ai données, et sur lesquelles on crache en continue (et là on se demande bien pourquoi). R.H.
[toc] | [prev] | [next] | [standalone]
| From | Richard Hachel <rh@tiscali.fr> |
|---|---|
| Date | 2025-08-28 14:47 +0000 |
| Message-ID | <lADmbNn89LDuwcZ_AEKo3uXg4-4@jntp> |
| In reply to | #665638 |
Le 27/08/2025 à 22:27, Python a écrit : > Le 27/08/2025 à 10:43, Thomas Heger a écrit : >> Am Mittwoch000027, 27.08.2025 um 00:39 schrieb Python: >>> Le 25/08/2025 à 14:43, Maciej Woźniak a écrit : >>>> On 8/25/2025 1:41 PM, Python wrote: >>>>> Le 25/08/2025 à 08:23, Thomas Heger a écrit : >>>>>> Am Sonntag000024, 24.08.2025 um 22:49 schrieb Paul B. Andersen: >>>>>>> ... >>>>>> Half of that is assumed to be the one way delay, but t_B is >>>>>> irrelevant and also unknown on Earth. >>>>>> >>>>>> The Earth station A can only measure t'_A and t_A. The difference is >>>>>> actually 'two way delay'. >>>>>> >>>>>> To measure t_B is difficult from Earth, if the clock there isn't >>>>>> extremly large. >>>>> >>>>> As an "engineer" couldn't you imagine a way for the t_B value read on >>>>> the Moon to be sent to A? Or for t_A and t'_A values to be sent to B? >>>> >>>> Well [...] - doesn't the nonsense of your >>>> idiot guru require no gravity and Moon not moving >>>> wrt Earth? >>> >>> This is Thomas' obsession with the Moon that brings us here. Of course >>> it leads to a lot of approximations, that actually make sense : gravity >>> is low and the Moon is not moving that fast wrt Earth. >>> >>> It is not my fault if he fails to grasp that what Einstein described is >>> more suited to clocks a few centimeters or meters away in a real lab >>> experiment. As I've shown you with a paper from CERN. >>> >>> BTW, do you think, also, that you cannot transmit a value recorded by a >>> clock on the Moon if this clock is not "extremely large"? After you're >>> both wannabee engineers :-) >>> >> >> The idea of Einstein was, that reading of a remote clock by e.g. a large >> telescope would be the time of the remote clock. >> >> (Einstein "Time is what clocks say") >> >> I meant, that this is not the case, because 'to see' requires light and >> that time to travel. > > " If at the point A of space there is a clock, an observer at A can determine > the time values of events in the immediate proximity of A by finding the positions > of the hands which are simultaneous with these events. If there is at the point B > of space another clock in all respects resembling the one at A, it is possible for > an observer at B to determine the time values of events in the immediate > neighbourhood of B. " > > the key parts you missed is "immediate proximity" and "immediate neighbourhood". Oui, mais quel rapport entre les deux horloges A et B? S'il existe une anisochronie (rupture de la notion de simultanéité, de "temps présent" commun) comment tu fais pour accorder "absolument" les montres? C'est impossible. En relativité, il va te falloir un fédérateur extérieur. J'ai expliqué lequel dans mon pdf. Nous avons la même chose avec les horloges solaires, l'une placée Boulevard Montmartre à Paris, l'autre placée dans le même boulevard, mais trois mètres plus loin. Elles donnent la même heure solaire. Mais transportons cette deuxième horloge à Berlin. La messe est dite. Il n'y a pas, il n'y aura jamais, de simultanéité solaire absolue. C'est ce principe qui explique l'effet relativiste du premier degré. Si nous nous déplacions très vite entre les deux horloges, un nouveau principe va encore perturber les choses, la chronotropie interne des montres va devenir relative. Non seulement les montres ne marquent pas la même heure, mais en plus, la montre qui joint A et B disjoncte complètement sa chronotropie INTERNE, et une nouvelle correction, du second degré apparait. Mais tu peux pas comprendre. T'euh qu'un bouffon. R.H.
[toc] | [prev] | [next] | [standalone]
Page 10 of 11 — ← Prev page 1 … 8 9 [10] 11 Next page →
Back to top | Article view | sci.physics.relativity
csiph-web