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 9 of 11 — ← Prev page 1 … 7 8 [9] 10 11 Next page →
| From | Thomas Heger <ttt_heg@web.de> |
|---|---|
| Date | 2025-08-28 10:05 +0200 |
| Message-ID | <mhagn9Fjv8pU2@mid.individual.net> |
| In reply to | #665638 |
Am Mittwoch000027, 27.08.2025 um 22:27 schrieb Python:
> 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".
>
Ok, A watches his clock at A and B his clock at B.
Now we want to synchronise both clocks.
How would you like to do that?
a) We could introduce a third observer at C, which is in the exact
middle between A nd B.
C would tell A to turn the hands of his clocks to the own 'C-time' and
do the same with B, which also had to turn the clock to 'C-time'.
Then A and B would also be in synch.
So far, so good.
BUT: this could only be done for two points (here A and B), not for
three, because three points build a triangle and the mid point of the
triangle isn't lying upon one of the edges.
Therefore 'midpoint-time' doesn't work for any other case than two points.
Next try:
b) you turn the hands of the clocks at B to A-time.
That method would work, but isn't symmetric, because the time at point B
('B-time') wouldn't be used at all.
Next try:
c) you turn the hands of the clocks at A to B-time.
This would work, but has the same disadvantages as the previous one.
NOw you have three bad options and have to chose one.
I took option b) from above and would synchronise the clock in point B
to 'A-time'.
That would make some sense and isn't violating too many assumptions
about the real world, which are regarded as valid.
Method a) was apparently what Einstein actually wanted, even if he
didn't say so.
I don't like this method, because it would introduce a third observer
(what is 'unnatural') and that would lead to infinite regress, if the
points A and C are also regarded as endpoint of an interval.
so I took method b) as method, which would make the most sense.
TH
[toc] | [prev] | [next] | [standalone]
| From | Python <jp@python.invalid> |
|---|---|
| Date | 2025-08-28 09:47 +0000 |
| Message-ID | <mp-_a47L8TguH8Rpeui6iEH3ARg@jntp> |
| In reply to | #665643 |
Le 28/08/2025 à 10:01, Thomas Heger a écrit :
> Am Mittwoch000027, 27.08.2025 um 22:27 schrieb Python:
>> 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".
>>
>
> Ok, A watches his clock at A and B his clock at B.
>
> Now we want to synchronise both clocks.
>
> How would you like to do that?
>
> a) We could introduce a third observer at C, which is in the exact
> middle between A nd B.
>
> C would tell A to turn the hands of his clocks to the own 'C-time' and
> do the same with B, which also had to turn the clock to 'C-time'.
>
> Then A and B would also be in synch.
>
> So far, so good.
>
> BUT: this could only be done for two points (here A and B), not for
> three, because three points build a triangle and the mid point of the
> triangle isn't lying upon one of the edges.
>
> Therefore 'midpoint-time' doesn't work for any other case than two points.
>
>
> Next try:
>
> b) you turn the hands of the clocks at B to A-time.
>
> That method would work, but isn't symmetric, because the time at point B
> ('B-time') wouldn't be used at all.
>
>
> Next try:
>
> c) you turn the hands of the clocks at A to B-time.
>
> This would work, but has the same disadvantages as the previous one.
>
>
> NOw you have three bad options and have to chose one.
>
>
> I took option b) from above and would synchronise the clock in point B
> to 'A-time'.
>
> That would make some sense and isn't violating too many assumptions
> about the real world, which are regarded as valid.
>
> Method a) was apparently what Einstein actually wanted, even if he
> didn't say so.
>
> I don't like this method, because it would introduce a third observer
> (what is 'unnatural') and that would lead to infinite regress, if the
> points A and C are also regarded as endpoint of an interval.
>
> so I took method b) as method, which would make the most sense.
>
> TH
Neither of these method makes sense.
The method described by Einstein makes sense :
Communicate t_A and t'_A to B and/or t_B to A.
Decide if either A or B should apply an offset to his clock.
Check if t_B - t_A = t_A' - t_B, if true then there is nothing to do :
clocks are synchronized.
If it's not compute the offset to apply so that it would have been true.
Replay the whole procedure if you wish, you should notice that clocks are
now synchronized.
This can be experimented at : https://noedge.net/e/
[toc] | [prev] | [next] | [standalone]
| From | Maciej Woźniak <mlwozniak@wp.pl> |
|---|---|
| Date | 2025-08-28 12:09 +0200 |
| Message-ID | <185fe66e3aaa4a67$1811143$2346581$c2065a8b@news.newsdemon.com> |
| In reply to | #665644 |
On 8/28/2025 11:47 AM, Python wrote:
> Le 28/08/2025 à 10:01, Thomas Heger a écrit :
>> Am Mittwoch000027, 27.08.2025 um 22:27 schrieb Python:
>>> 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".
>>>
>>
>> Ok, A watches his clock at A and B his clock at B.
>>
>> Now we want to synchronise both clocks.
>>
>> How would you like to do that?
>>
>> a) We could introduce a third observer at C, which is in the exact
>> middle between A nd B.
>>
>> C would tell A to turn the hands of his clocks to the own 'C-time' and
>> do the same with B, which also had to turn the clock to 'C-time'.
>>
>> Then A and B would also be in synch.
>>
>> So far, so good.
>>
>> BUT: this could only be done for two points (here A and B), not for
>> three, because three points build a triangle and the mid point of the
>> triangle isn't lying upon one of the edges.
>>
>> Therefore 'midpoint-time' doesn't work for any other case than two
>> points.
>>
>>
>> Next try:
>>
>> b) you turn the hands of the clocks at B to A-time.
>>
>> That method would work, but isn't symmetric, because the time at point
>> B ('B-time') wouldn't be used at all.
>>
>>
>> Next try:
>>
>> c) you turn the hands of the clocks at A to B-time.
>>
>> This would work, but has the same disadvantages as the previous one.
>>
>>
>> NOw you have three bad options and have to chose one.
>>
>>
>> I took option b) from above and would synchronise the clock in point B
>> to 'A-time'.
>>
>> That would make some sense and isn't violating too many assumptions
>> about the real world, which are regarded as valid.
>>
>> Method a) was apparently what Einstein actually wanted, even if he
>> didn't say so.
>>
>> I don't like this method, because it would introduce a third observer
>> (what is 'unnatural') and that would lead to infinite regress, if the
>> points A and C are also regarded as endpoint of an interval.
>>
>> so I took method b) as method, which would make the most sense.
>>
>> TH
>
> Neither of these method makes sense.
>
> The method described by Einstein makes sense :
No, it doesn't. Its requirements are ridiculous,
even when taking the postulates behind it
seriously.
[toc] | [prev] | [next] | [standalone]
| From | Richard Hachel <rh@tiscali.fr> |
|---|---|
| Date | 2025-08-28 14:57 +0000 |
| Message-ID | <FmJNWPeVc4OdE4btIKmBJ632v50@jntp> |
| In reply to | #665644 |
Le 28/08/2025 à 11:47, Python a écrit :
> Le 28/08/2025 à 10:01, Thomas Heger a écrit :
>> Am Mittwoch000027, 27.08.2025 um 22:27 schrieb Python:
>>> 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".
>>>
>>
>> Ok, A watches his clock at A and B his clock at B.
>>
>> Now we want to synchronise both clocks.
>>
>> How would you like to do that?
>>
>> a) We could introduce a third observer at C, which is in the exact
>> middle between A nd B.
>>
>> C would tell A to turn the hands of his clocks to the own 'C-time' and
>> do the same with B, which also had to turn the clock to 'C-time'.
>>
>> Then A and B would also be in synch.
>>
>> So far, so good.
>>
>> BUT: this could only be done for two points (here A and B), not for
>> three, because three points build a triangle and the mid point of the
>> triangle isn't lying upon one of the edges.
>>
>> Therefore 'midpoint-time' doesn't work for any other case than two points.
>>
>>
>> Next try:
>>
>> b) you turn the hands of the clocks at B to A-time.
>>
>> That method would work, but isn't symmetric, because the time at point B
>> ('B-time') wouldn't be used at all.
>>
>>
>> Next try:
>>
>> c) you turn the hands of the clocks at A to B-time.
>>
>> This would work, but has the same disadvantages as the previous one.
>>
>>
>> NOw you have three bad options and have to chose one.
>>
>>
>> I took option b) from above and would synchronise the clock in point B
>> to 'A-time'.
>>
>> That would make some sense and isn't violating too many assumptions
>> about the real world, which are regarded as valid.
>>
>> Method a) was apparently what Einstein actually wanted, even if he
>> didn't say so.
>>
>> I don't like this method, because it would introduce a third observer
>> (what is 'unnatural') and that would lead to infinite regress, if the
>> points A and C are also regarded as endpoint of an interval.
>>
>> so I took method b) as method, which would make the most sense.
>>
>> TH
>
> Neither of these method makes sense.
>
> The method described by Einstein makes sense :
>
> Communicate t_A and t'_A to B and/or t_B to A.
>
> Decide if either A or B should apply an offset to his clock.
>
> Check if t_B - t_A = t_A' - t_B, if true then there is nothing to do : clocks
> are synchronized.
>
> If it's not compute the offset to apply so that it would have been true.
>
> Replay the whole procedure if you wish, you should notice that clocks are now
> synchronized.
>
> This can be experimented at : https://noedge.net/e/
Purpipo ridicule.
Mais quel guignol, celui-là!
Cette procédure est débile, complétement hors propos en relativité
restreinte.
La notion de simultanéité absolue n'existant pas, même dans un simple
référentiel inertiel.
Juliette assise sur ce banc, Romeo assis sur cet autre, trente mètres
plus loin, ne pourront jamais accorder leurs montres.
Certes, dans notre monde macroscopique, il est midi sur les deux montres,
et cela suffit à leur confort.
Mais à l'échelle relativiste, les deux montres "voient" l'autre montre
retarder de 100 nanosecondes en permanence, leur hyperplan de temps
présent étant différent.
Si tu ne prends pas en compte cette anisochronie universelle, Δ=AB.Et
("Et" étant l'écart-temps ou anisochronie), toutes tes explications
resteront finalement newtoniennes et insuffisantes, et tes travaux
scientifiques de vulgarisation voués à l'échec au final.
R.H.
R.H.
[toc] | [prev] | [next] | [standalone]
| From | Thomas Heger <ttt_heg@web.de> |
|---|---|
| Date | 2025-08-29 09:36 +0200 |
| Message-ID | <mhd3c4F2510U6@mid.individual.net> |
| In reply to | #665647 |
Am Donnerstag000028, 28.08.2025 um 16:57 schrieb Richard Hachel:
> Le 28/08/2025 à 11:47, Python a écrit :
>> Le 28/08/2025 à 10:01, Thomas Heger a écrit :
>>> Am Mittwoch000027, 27.08.2025 um 22:27 schrieb Python:
>>>> 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".
>>>>
>>>
>>> Ok, A watches his clock at A and B his clock at B.
>>>
>>> Now we want to synchronise both clocks.
>>>
>>> How would you like to do that?
>>>
>>> a) We could introduce a third observer at C, which is in the exact
>>> middle between A nd B.
>>>
>>> C would tell A to turn the hands of his clocks to the own 'C-time'
>>> and do the same with B, which also had to turn the clock to 'C-time'.
>>>
>>> Then A and B would also be in synch.
>>>
>>> So far, so good.
>>>
>>> BUT: this could only be done for two points (here A and B), not for
>>> three, because three points build a triangle and the mid point of the
>>> triangle isn't lying upon one of the edges.
>>>
>>> Therefore 'midpoint-time' doesn't work for any other case than two
>>> points.
>>>
>>>
>>> Next try:
>>>
>>> b) you turn the hands of the clocks at B to A-time.
>>>
>>> That method would work, but isn't symmetric, because the time at
>>> point B ('B-time') wouldn't be used at all.
>>>
>>>
>>> Next try:
>>>
>>> c) you turn the hands of the clocks at A to B-time.
>>>
>>> This would work, but has the same disadvantages as the previous one.
>>>
>>>
>>> NOw you have three bad options and have to chose one.
>>>
>>>
>>> I took option b) from above and would synchronise the clock in point
>>> B to 'A-time'.
>>>
>>> That would make some sense and isn't violating too many assumptions
>>> about the real world, which are regarded as valid.
>>>
>>> Method a) was apparently what Einstein actually wanted, even if he
>>> didn't say so.
>>>
>>> I don't like this method, because it would introduce a third observer
>>> (what is 'unnatural') and that would lead to infinite regress, if the
>>> points A and C are also regarded as endpoint of an interval.
>>>
>>> so I took method b) as method, which would make the most sense.
>>>
>>> TH
>>
>> Neither of these method makes sense.
>>
>> The method described by Einstein makes sense :
>>
>> Communicate t_A and t'_A to B and/or t_B to A.
>>
>> Decide if either A or B should apply an offset to his clock.
>>
>> Check if t_B - t_A = t_A' - t_B, if true then there is nothing to do :
>> clocks are synchronized.
>>
>> If it's not compute the offset to apply so that it would have been true.
>>
>> Replay the whole procedure if you wish, you should notice that clocks
>> are now synchronized.
>>
>> This can be experimented at : https://noedge.net/e/
>
> Purpipo ridicule.
>
> Mais quel guignol, celui-là!
> Cette procédure est débile, complétement hors propos en relativité
> restreinte.
>
> La notion de simultanéité absolue n'existant pas, même dans un simple
> référentiel inertiel.
>
> Juliette assise sur ce banc, Romeo assis sur cet autre, trente mètres
> plus loin, ne pourront jamais accorder leurs montres.
> Certes, dans notre monde macroscopique, il est midi sur les deux
> montres, et cela suffit à leur confort.
> Mais à l'échelle relativiste, les deux montres "voient" l'autre montre
> retarder de 100 nanosecondes en permanence, leur hyperplan de temps
> présent étant différent.
> Si tu ne prends pas en compte cette anisochronie universelle, Δ=AB.Et
> ("Et" étant l'écart-temps ou anisochronie), toutes tes explications
> resteront finalement newtoniennes et insuffisantes, et tes travaux
> scientifiques de vulgarisation voués à l'échec au final.
> R.H.
>
English would be better in this forum!
Anhow..
The 'hyperplane of the present' is not visible, but real.
It is not visible, because it connects infinitively fast, what light
cannot do.
Light is fast, however, but not that fast.
To deal with this discrepancy, we had to reject the actual visual
impression of something remote and must think, that what we see remote
is a picture, we receive from the past.
It is longer ago the further away, hence the picture is actually
'layered in time'.
Therefore the 'hyperplane of the present' is not what we can see in the
night sky.
Both differ from each other to a certain degree and cannot become
reunited at all.
This is so, because an event in say 3 ly distance will be visible in
three years and one in 3 million ly distance in three million years.
Therefore those two events can never be seen together, even if they
happen at the same time.
To say, that an event seen in 3 mio ly is happening now, because we can
see it now, would be a horendous mistake.
Therefore the 'hyperplane of the present' is not visible at all.
Only a very small part can actually be seen in the direct vicinity.
Everything else can only be seen with a certain delay.
TH
[toc] | [prev] | [next] | [standalone]
| From | Richard Hachel <rh@tiscali.fr> |
|---|---|
| Date | 2025-08-29 12:00 +0000 |
| Message-ID | <dJTtyvEbkkX_E1RaMtNfNkbwbe0@jntp> |
| In reply to | #665660 |
Le 29/08/2025 à 09:32, Thomas Heger a écrit : > The 'hyperplane of the present' is not visible, but real. > > It is not visible, because it connects infinitively fast, what light > cannot do. > > Light is fast, however, but not that fast. > > To deal with this discrepancy, we had to reject the actual visual > impression of something remote and must think, that what we see remote > is a picture, we receive from the past. > > It is longer ago the further away, hence the picture is actually > 'layered in time'. > > Therefore the 'hyperplane of the present' is not what we can see in the > night sky. > > Both differ from each other to a certain degree and cannot become > reunited at all. > > This is so, because an event in say 3 ly distance will be visible in > three years and one in 3 million ly distance in three million years. > > Therefore those two events can never be seen together, even if they > happen at the same time. > > To say, that an event seen in 3 mio ly is happening now, because we can > see it now, would be a horendous mistake. > > Therefore the 'hyperplane of the present' is not visible at all. > > Only a very small part can actually be seen in the direct vicinity. > Everything else can only be seen with a certain delay. I see that you clearly haven't understood anything I've been saying for forty years. This anisochrony thing is very simple to understand; it simply indicates that the notion of a present-time hyperplane is specific to each observer, and that two observers only have the same time if they are conjoined (that is, in the same place even if their speeds are very different). I feel like I'm talking to middle schoolers who don't understand anything at all. If you're already stuck there, how can you understand this fantastic flash of genius that consists of stating: D'=D.qsrt(1-Vo²/c²)/(1+cosµ.Vo/c), which is mathematically and physically very logical, but conceptually very disorienting. Elastic to this point, space is no longer friendly. The human mind goes off the rails and prefers to say that 9 times 4 equals 7.2, which is absurd when viewed from the other side of the telescope. R.H.
[toc] | [prev] | [next] | [standalone]
| From | The Starmaker <starmaker@ix.netcom.com> |
|---|---|
| Date | 2025-08-29 07:42 -0700 |
| Message-ID | <4be3bkt0vksqfspjpusvbb2nrso9b8kfpk@4ax.com> |
| In reply to | #665668 |
On Fri, 29 Aug 25 12:00:38 +0000, Richard Hachel <rh@tiscali.fr> wrote: >Le 29/08/2025 à 09:32, Thomas Heger a écrit : >> The 'hyperplane of the present' is not visible, but real. >> >> It is not visible, because it connects infinitively fast, what light >> cannot do. >> >> Light is fast, however, but not that fast. >> >> To deal with this discrepancy, we had to reject the actual visual >> impression of something remote and must think, that what we see remote >> is a picture, we receive from the past. >> >> It is longer ago the further away, hence the picture is actually >> 'layered in time'. >> >> Therefore the 'hyperplane of the present' is not what we can see in the >> night sky. >> >> Both differ from each other to a certain degree and cannot become >> reunited at all. >> >> This is so, because an event in say 3 ly distance will be visible in >> three years and one in 3 million ly distance in three million years. >> >> Therefore those two events can never be seen together, even if they >> happen at the same time. >> >> To say, that an event seen in 3 mio ly is happening now, because we can >> see it now, would be a horendous mistake. >> >> Therefore the 'hyperplane of the present' is not visible at all. >> >> Only a very small part can actually be seen in the direct vicinity. >> Everything else can only be seen with a certain delay. > >I see that you clearly haven't understood anything I've been saying for >forty years. >R.H. You should take a big knife put it in your French girlfriends hand and tell her... "I see that you clearly haven't understood anything I've been saying for forty years!!!!" https://www.youtube.com/shorts/i1-nBqeTfSo
[toc] | [prev] | [next] | [standalone]
| From | Thomas Heger <ttt_heg@web.de> |
|---|---|
| Date | 2025-08-30 09:32 +0200 |
| Message-ID | <mhfngeFfnejU6@mid.individual.net> |
| In reply to | #665668 |
Am Freitag000029, 29.08.2025 um 14:00 schrieb Richard Hachel: > Le 29/08/2025 à 09:32, Thomas Heger a écrit : >> The 'hyperplane of the present' is not visible, but real. >> >> It is not visible, because it connects infinitively fast, what light >> cannot do. >> >> Light is fast, however, but not that fast. >> >> To deal with this discrepancy, we had to reject the actual visual >> impression of something remote and must think, that what we see remote >> is a picture, we receive from the past. >> >> It is longer ago the further away, hence the picture is actually >> 'layered in time'. >> >> Therefore the 'hyperplane of the present' is not what we can see in >> the night sky. >> >> Both differ from each other to a certain degree and cannot become >> reunited at all. >> >> This is so, because an event in say 3 ly distance will be visible in >> three years and one in 3 million ly distance in three million years. >> >> Therefore those two events can never be seen together, even if they >> happen at the same time. >> >> To say, that an event seen in 3 mio ly is happening now, because we >> can see it now, would be a horendous mistake. >> >> Therefore the 'hyperplane of the present' is not visible at all. >> >> Only a very small part can actually be seen in the direct vicinity. >> Everything else can only be seen with a certain delay. > > I see that you clearly haven't understood anything I've been saying for > forty years. > This anisochrony thing is very simple to understand; it simply indicates > that the notion of a present-time hyperplane is specific to each > observer, and that two observers only have the same time if they are > conjoined (that is, in the same place even if their speeds are very > different). I wanted to define 'in synch' by another system, where the 'hyperplane of the present' actually represents a connection with infinite velocity. In 'spacetime terms' it has no 'thickness'. That means, the time across in the direction of time is zero. This could imagined, anyhow, by introducing a signal, which does not exist in reality. This would connect (if it would exist) across the entire hyperplane of the present, but without any delay. This hyperplane of the present would be comoving with the observer under consideration, hence would be 'relative'. Other observers have therefore other hyperplanes of their present, which is comoving to them. Now we have a common experience, that the surface of the Earth is actually a sperical sheet, which belongs to the same 'time-domain', because time around the globe streams in roughly the same manner. But this changes with hight and possibly with other parameters, like e.g. acceleration. Now this picture seems not very satisfying. But there is a very interesting application to this method: we could associate 'infinitely fast influences' with a static field. This means, that static fields are 'relative' and only appear to be static from a certain perspective (which is the timeline of the observer). We could e.g. call a standing rotation wave 'static', if the observer moves with it and in the same direction and at the same pace (along the imaginary axis of time). This would fit now to the description of an atom, if we regard atoms as 'timelike stable patterns' (what I did). This in turn would allow matter to be created from nothing or to disappear without a trace. For both of these possibilities there are examples. 'matter out of nowhere' would fit to big-bang, for instance, but also to 'Growing Earth'. ... TH
[toc] | [prev] | [next] | [standalone]
| From | Richard Hachel <rh@tiscali.fr> |
|---|---|
| Date | 2025-08-30 13:33 +0000 |
| Message-ID | <8wfK03lMswWTf2FTUr8EYvnXhSg@jntp> |
| In reply to | #665680 |
Le 30/08/2025 à 09:28, Thomas Heger a écrit : > Am Freitag000029, 29.08.2025 um 14:00 schrieb Richard Hachel: >> Le 29/08/2025 à 09:32, Thomas Heger a écrit : >>> The 'hyperplane of the present' is not visible, but real. >>> >>> It is not visible, because it connects infinitively fast, what light >>> cannot do. >>> >>> Light is fast, however, but not that fast. >>> >>> To deal with this discrepancy, we had to reject the actual visual >>> impression of something remote and must think, that what we see remote >>> is a picture, we receive from the past. >>> >>> It is longer ago the further away, hence the picture is actually >>> 'layered in time'. >>> >>> Therefore the 'hyperplane of the present' is not what we can see in >>> the night sky. >>> >>> Both differ from each other to a certain degree and cannot become >>> reunited at all. >>> >>> This is so, because an event in say 3 ly distance will be visible in >>> three years and one in 3 million ly distance in three million years. >>> >>> Therefore those two events can never be seen together, even if they >>> happen at the same time. >>> >>> To say, that an event seen in 3 mio ly is happening now, because we >>> can see it now, would be a horendous mistake. >>> >>> Therefore the 'hyperplane of the present' is not visible at all. >>> >>> Only a very small part can actually be seen in the direct vicinity. >>> Everything else can only be seen with a certain delay. >> >> I see that you clearly haven't understood anything I've been saying for >> forty years. >> This anisochrony thing is very simple to understand; it simply indicates >> that the notion of a present-time hyperplane is specific to each >> observer, and that two observers only have the same time if they are >> conjoined (that is, in the same place even if their speeds are very >> different). > > I wanted to define 'in synch' by another system, where the 'hyperplane > of the present' actually represents a connection with infinite velocity. > > In 'spacetime terms' it has no 'thickness'. That means, the time across > in the direction of time is zero. > > This could imagined, anyhow, by introducing a signal, which does not > exist in reality. > > This would connect (if it would exist) across the entire hyperplane of > the present, but without any delay. > > This hyperplane of the present would be comoving with the observer under > consideration, hence would be 'relative'. > > Other observers have therefore other hyperplanes of their present, which > is comoving to them. > > Now we have a common experience, that the surface of the Earth is > actually a sperical sheet, which belongs to the same 'time-domain', > because time around the globe streams in roughly the same manner. > > But this changes with hight and possibly with other parameters, like > e.g. acceleration. > > Now this picture seems not very satisfying. > > But there is a very interesting application to this method: > > we could associate 'infinitely fast influences' with a static field. > > This means, that static fields are 'relative' and only appear to be > static from a certain perspective (which is the timeline of the observer). > > We could e.g. call a standing rotation wave 'static', if the observer > moves with it and in the same direction and at the same pace (along the > imaginary axis of time). > > This would fit now to the description of an atom, if we regard atoms as > 'timelike stable patterns' (what I did). > > This in turn would allow matter to be created from nothing or to > disappear without a trace. > > For both of these possibilities there are examples. > > 'matter out of nowhere' would fit to big-bang, for instance, but also to > 'Growing Earth'. > > > > ... > TH Ce n'est pas du tout ce que je tente de t'expliquer. R.H.
[toc] | [prev] | [next] | [standalone]
| From | Thomas Heger <ttt_heg@web.de> |
|---|---|
| Date | 2025-08-31 09:53 +0200 |
| Message-ID | <mhid55Ftki9U5@mid.individual.net> |
| In reply to | #665698 |
Am Samstag000030, 30.08.2025 um 15:33 schrieb Richard Hachel: > Le 30/08/2025 à 09:28, Thomas Heger a écrit : >> Am Freitag000029, 29.08.2025 um 14:00 schrieb Richard Hachel: >>> Le 29/08/2025 à 09:32, Thomas Heger a écrit : >>>> The 'hyperplane of the present' is not visible, but real. >>>> >>>> It is not visible, because it connects infinitively fast, what light >>>> cannot do. >>>> >>>> Light is fast, however, but not that fast. >>>> >>>> To deal with this discrepancy, we had to reject the actual visual >>>> impression of something remote and must think, that what we see >>>> remote is a picture, we receive from the past. >>>> >>>> It is longer ago the further away, hence the picture is actually >>>> 'layered in time'. >>>> >>>> Therefore the 'hyperplane of the present' is not what we can see in >>>> the night sky. >>>> >>>> Both differ from each other to a certain degree and cannot become >>>> reunited at all. >>>> >>>> This is so, because an event in say 3 ly distance will be visible in >>>> three years and one in 3 million ly distance in three million years. >>>> >>>> Therefore those two events can never be seen together, even if they >>>> happen at the same time. >>>> >>>> To say, that an event seen in 3 mio ly is happening now, because we >>>> can see it now, would be a horendous mistake. >>>> >>>> Therefore the 'hyperplane of the present' is not visible at all. >>>> >>>> Only a very small part can actually be seen in the direct vicinity. >>>> Everything else can only be seen with a certain delay. >>> >>> I see that you clearly haven't understood anything I've been saying >>> for forty years. >>> This anisochrony thing is very simple to understand; it simply >>> indicates that the notion of a present-time hyperplane is specific to >>> each observer, and that two observers only have the same time if they >>> are conjoined (that is, in the same place even if their speeds are >>> very different). >> >> I wanted to define 'in synch' by another system, where the 'hyperplane >> of the present' actually represents a connection with infinite velocity. >> >> In 'spacetime terms' it has no 'thickness'. That means, the time >> across in the direction of time is zero. >> >> This could imagined, anyhow, by introducing a signal, which does not >> exist in reality. >> >> This would connect (if it would exist) across the entire hyperplane of >> the present, but without any delay. >> >> This hyperplane of the present would be comoving with the observer >> under consideration, hence would be 'relative'. >> >> Other observers have therefore other hyperplanes of their present, >> which is comoving to them. >> >> Now we have a common experience, that the surface of the Earth is >> actually a sperical sheet, which belongs to the same 'time-domain', >> because time around the globe streams in roughly the same manner. >> >> But this changes with hight and possibly with other parameters, like >> e.g. acceleration. >> >> Now this picture seems not very satisfying. >> >> But there is a very interesting application to this method: >> >> we could associate 'infinitely fast influences' with a static field. >> >> This means, that static fields are 'relative' and only appear to be >> static from a certain perspective (which is the timeline of the >> observer). >> >> We could e.g. call a standing rotation wave 'static', if the observer >> moves with it and in the same direction and at the same pace (along >> the imaginary axis of time). >> >> This would fit now to the description of an atom, if we regard atoms >> as 'timelike stable patterns' (what I did). >> >> This in turn would allow matter to be created from nothing or to >> disappear without a trace. >> >> For both of these possibilities there are examples. >> >> 'matter out of nowhere' would fit to big-bang, for instance, but also >> to 'Growing Earth'. >> >> >> >> ... >> TH > > Ce n'est pas du tout ce que je tente de t'expliquer. > "That's not at all what I'm trying to explain to you." (French isn't a good idea for this group). Well, you seemingly have some other concepts for relativty than those that I have. And most likely you are correct. But I use a certain 'backdrop' and that is Minkowski's spacetime and Poincare's concept local time. The observer is in this picture 'self-centered' and rests permanently in the center of the own frame of reference. Therefore any observer regards the own time a valid and running forward, while the observed universe is actually not universal, but the observer's own past light-cone. The axis of time is regarded as imaginary axis and the relations connecting with other objects are assumed to behave like complex quaternions. Now: what means 'simultaneous'? I take the axis of time of the local observer and construct its inverse, which is called 'hyperplane of the present'. All events upon that 'hyperplane of the present' are simultaneous for that observer in question. But this ain't universal, because already the axis of time isn't. Actually I would allow timelines, which run bachwards from the perspective of the observer. Also 'sideways' time would be possible. This is a possibility, because also matter is 'relative'. Therefore, if we could turn the axis of time a bit, we would see an entirely different universe, filled with other matter and other stars. TH
[toc] | [prev] | [next] | [standalone]
| From | Richard Hachel <rh@tiscali.fr> |
|---|---|
| Date | 2025-08-31 10:36 +0000 |
| Message-ID | <7cFv6jgvHwaKx4uOOkxLkPxypNM@jntp> |
| In reply to | #665709 |
Le 31/08/2025 à 09:49, Thomas Heger a écrit : > Am Samstag000030, 30.08.2025 um 15:33 schrieb Richard Hachel: > Now: what means 'simultaneous'? A and B are in the SAME frame of reference, but not at the same place. <http://nemoweb.net/jntp?7cFv6jgvHwaKx4uOOkxLkPxypNM@jntp/Data.Media:1> > TH R.H.
[toc] | [prev] | [next] | [standalone]
| From | Thomas Heger <ttt_heg@web.de> |
|---|---|
| Date | 2025-08-29 09:19 +0200 |
| Message-ID | <mhd2ckF2510U5@mid.individual.net> |
| In reply to | #665644 |
Am Donnerstag000028, 28.08.2025 um 11:47 schrieb Python:
> Le 28/08/2025 à 10:01, Thomas Heger a écrit :
>> Am Mittwoch000027, 27.08.2025 um 22:27 schrieb Python:
>>> 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".
>>>
>>
>> Ok, A watches his clock at A and B his clock at B.
>>
>> Now we want to synchronise both clocks.
>>
>> How would you like to do that?
>>
>> a) We could introduce a third observer at C, which is in the exact
>> middle between A nd B.
>>
>> C would tell A to turn the hands of his clocks to the own 'C-time' and
>> do the same with B, which also had to turn the clock to 'C-time'.
>>
>> Then A and B would also be in synch.
>>
>> So far, so good.
>>
>> BUT: this could only be done for two points (here A and B), not for
>> three, because three points build a triangle and the mid point of the
>> triangle isn't lying upon one of the edges.
>>
>> Therefore 'midpoint-time' doesn't work for any other case than two
>> points.
>>
>>
>> Next try:
>>
>> b) you turn the hands of the clocks at B to A-time.
>>
>> That method would work, but isn't symmetric, because the time at point
>> B ('B-time') wouldn't be used at all.
>>
>>
>> Next try:
>>
>> c) you turn the hands of the clocks at A to B-time.
>>
>> This would work, but has the same disadvantages as the previous one.
>>
>>
>> NOw you have three bad options and have to chose one.
>>
>>
>> I took option b) from above and would synchronise the clock in point B
>> to 'A-time'.
>>
>> That would make some sense and isn't violating too many assumptions
>> about the real world, which are regarded as valid.
>>
>> Method a) was apparently what Einstein actually wanted, even if he
>> didn't say so.
>>
>> I don't like this method, because it would introduce a third observer
>> (what is 'unnatural') and that would lead to infinite regress, if the
>> points A and C are also regarded as endpoint of an interval.
>>
>> so I took method b) as method, which would make the most sense.
>>
>> TH
>
> Neither of these method makes sense.
>
> The method described by Einstein makes sense :
'The method described by Einstein' would require a description in
Einstein's text.
But no such discription can be found in 'On the electrodynamics of
moving bodies'.>
> Communicate t_A and t'_A to B and/or t_B to A.
Sure, that would make sense. But the only thing close to your statement
would have been to read the clock at B from point A through a large
telescope.
(Alternativly the clock at A could be read from B.)
But time values like t_A or t'_A cannot be communicated from A to B,
because there were only clocks and no other means to encode time values
into light signals.
> Decide if either A or B should apply an offset to his clock.
Sure, but I have actually mentioned this already.
I had chosen B to adjust his clock.
> Check if t_B - t_A = t_A' - t_B, if true then there is nothing to do :
> clocks are synchronized.
To subtract time values from distant locations, you would need to
transfer one of such values to the other station and measure the other
value there.
But where have you found a description of this method in Einstein's paper?
> If it's not compute the offset to apply so that it would have been true.
'to compute' means something like a numerical calculation.
To do that, you would need to have numerical values and some means to do
that calculation.
But how would you transfer e.g. t_B from B to A?
One method (if B is not too far away): look at point A thorugh a
telescope at a clock at point B.
In this case you would need to add the delay to the reading of the
remote clock.
other more modern means would use e.g. lasers and encoded time signals.
But in any case you need to know the delay.
TH> Replay the whole procedure if you wish, you should notice that clocks
> are now synchronized.
>
> This can be experimented at : https://noedge.net/e/
>
>
>
[toc] | [prev] | [next] | [standalone]
| From | Python <jp@python.invalid> |
|---|---|
| Date | 2025-08-29 10:00 +0000 |
| Message-ID | <gZnt07SVYtVzMFfSMHhieXLLDCs@jntp> |
| In reply to | #665659 |
Le 29/08/2025 à 09:15, Thomas Heger a écrit : .. > To do that, you would need to have numerical values and some means to do > that calculation. > > But how would you transfer e.g. t_B from B to A? Sigh... By carrier pigeon, snail mail, any mean. It doesn't matter. Thomas you are definitely NOT a member of the intended audience (i.e. non demented people) of Einstein's article if you cannot guess this at first read. Sorry.
[toc] | [prev] | [next] | [standalone]
| From | Thomas Heger <ttt_heg@web.de> |
|---|---|
| Date | 2025-08-29 12:24 +0200 |
| Message-ID | <mhdd71F4flgU1@mid.individual.net> |
| In reply to | #665663 |
Am Freitag000029, 29.08.2025 um 12:00 schrieb Python: > Le 29/08/2025 à 09:15, Thomas Heger a écrit : > .. >> To do that, you would need to have numerical values and some means to >> do that calculation. >> >> But how would you transfer e.g. t_B from B to A? > > Sigh... By carrier pigeon, snail mail, any mean. It doesn't matter. > > Thomas you are definitely NOT a member of the intended audience (i.e. > non demented people) of Einstein's article if you cannot guess this at > first read. Sorry. > > 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. TH
[toc] | [prev] | [next] | [standalone]
| From | Python <jp@python.invalid> |
|---|---|
| Date | 2025-08-29 10:33 +0000 |
| Message-ID | <qYvj5b6A91ElKyghou-Wt6FKI7s@jntp> |
| In reply to | #665664 |
Le 29/08/2025 à 12:20, Thomas Heger a écrit : > Am Freitag000029, 29.08.2025 um 12:00 schrieb Python: >> Le 29/08/2025 à 09:15, Thomas Heger a écrit : >> .. >>> To do that, you would need to have numerical values and some means to >>> do that calculation. >>> >>> But how would you transfer e.g. t_B from B to A? >> >> Sigh... By carrier pigeon, snail mail, any mean. It doesn't matter. >> >> Thomas you are definitely NOT a member of the intended audience (i.e. >> non demented people) of Einstein's article if you cannot guess this at >> first read. Sorry. >> >> > > 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. Sigh, sigh, sigh. Are you sure you are not retarded ?
[toc] | [prev] | [next] | [standalone]
| From | Maciej Woźniak <mlwozniak@wp.pl> |
|---|---|
| Date | 2025-08-29 13:50 +0200 |
| Message-ID | <18603a8e89e2c035$17770$2382441$c2065a8b@news.newsdemon.com> |
| In reply to | #665665 |
On 8/29/2025 12:33 PM, Python wrote: > Le 29/08/2025 à 12:20, Thomas Heger a écrit : >> Am Freitag000029, 29.08.2025 um 12:00 schrieb Python: >>> Le 29/08/2025 à 09:15, Thomas Heger a écrit : >>> .. >>>> To do that, you would need to have numerical values and some means >>>> to do that calculation. >>>> >>>> But how would you transfer e.g. t_B from B to A? >>> >>> Sigh... By carrier pigeon, snail mail, any mean. It doesn't matter. >>> >>> Thomas you are definitely NOT a member of the intended audience (i.e. >>> non demented people) of Einstein's article if you cannot guess this >>> at first read. Sorry. >>> >>> >> >> 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. Together with some utterly idiotic *postulates*. Fortunately - only in unreachable conditions.
[toc] | [prev] | [next] | [standalone]
| From | Thomas Heger <ttt_heg@web.de> |
|---|---|
| Date | 2025-08-30 09:02 +0200 |
| Message-ID | <mhflogFfnejU4@mid.individual.net> |
| In reply to | #665665 |
Am Freitag000029, 29.08.2025 um 12:33 schrieb Python: > Le 29/08/2025 à 12:20, Thomas Heger a écrit : >> Am Freitag000029, 29.08.2025 um 12:00 schrieb Python: >>> Le 29/08/2025 à 09:15, Thomas Heger a écrit : >>> .. >>>> To do that, you would need to have numerical values and some means >>>> to do that calculation. >>>> >>>> But how would you transfer e.g. t_B from B to A? >>> >>> Sigh... By carrier pigeon, snail mail, any mean. It doesn't matter. >>> >>> Thomas you are definitely NOT a member of the intended audience (i.e. >>> non demented people) of Einstein's article if you cannot guess this >>> at first read. Sorry. >>> >>> >> >> 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? One possibility: there is a HUGE clock and A peeps through a huge telescope and reads out the clock himself. That would work, but only if A adds the time for transit of the light from B to A to the reading. In case of the Moon, which is B in this example, the observer at A (Houston Texas in this case) would read out a clock on the Moon, which says e.g. '13:00:00 Moon-meantime'. The observer in Houston would interpret this as '13:00:01 Mmt', because he knows, the reading would be one second late. 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. This doesn't work at all, because the delay is way too long and of uncertain length. Another possibility: the clock upon the Moon and the observer there are replaced by an automated system, which sends encoded messages, which contain the time values in a form, that a computer could understand. This are received in rural Texas by a huge antenna and transmitted to the station 'A'. This would work, but is only a different form of example one. ... TH > >
[toc] | [prev] | [next] | [standalone]
| From | Python <jp@python.invalid> |
|---|---|
| Date | 2025-08-30 09:53 +0000 |
| Message-ID | <BIe1RUhixeR_2WuS72suUbInznE@jntp> |
| In reply to | #665678 |
Le 30/08/2025 à 08:58, Thomas Heger a écrit : > Am Freitag000029, 29.08.2025 um 12:33 schrieb Python: >> Le 29/08/2025 à 12:20, Thomas Heger a écrit : >>> Am Freitag000029, 29.08.2025 um 12:00 schrieb Python: >>>> Le 29/08/2025 à 09:15, Thomas Heger a écrit : >>>> .. >>>>> To do that, you would need to have numerical values and some means >>>>> to do that calculation. >>>>> >>>>> But how would you transfer e.g. t_B from B to A? >>>> >>>> Sigh... By carrier pigeon, snail mail, any mean. It doesn't matter. >>>> >>>> Thomas you are definitely NOT a member of the intended audience (i.e. >>>> non demented people) of Einstein's article if you cannot guess this >>>> at first read. Sorry. >>>> >>>> >>> >>> 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.
[toc] | [prev] | [next] | [standalone]
| From | Slobodan Miheenkov <so@kobn.ru> |
|---|---|
| Date | 2025-08-30 10:23 +0000 |
| Message-ID | <108ujer$2i11l$1@dont-email.me> |
| In reply to | #665682 |
Python wrote: > Le 30/08/2025 à 08:58, Thomas Heger a écrit : >>> 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. yet another idiot not undrestanding relativity, nor is familiar with education and so on, not knowing that due effects, the signal changes, time changes, not knowing the sent value it's impossible to adapt, making the received value irrelevant.
[toc] | [prev] | [next] | [standalone]
| From | Thomas Heger <ttt_heg@web.de> |
|---|---|
| Date | 2025-08-31 09:13 +0200 |
| Message-ID | <mhiapfFtki9U2@mid.individual.net> |
| In reply to | #665682 |
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'. What would you do with that??? You would actually need to have an event, which an observer at point B could recognize and measure its time. But if A watches B's clocks through a large telescope, there ain't no such event. A light signal could be used, however, if A sends a 'blink' to the remote station and the observer measures (in measures ob B-time), when this signal arrives. Then the 'man on the Moon', for instance, could transmit the value of, say, '13:00:01' to the station A. This could be done by any available means (which would -at least- exclude pigeons, mail, sound or thrown papers). Anyhow: Now Houston has this information. And what next? TH
[toc] | [prev] | [next] | [standalone]
Page 9 of 11 — ← Prev page 1 … 7 8 [9] 10 11 Next page →
Back to top | Article view | sci.physics.relativity
csiph-web