Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #396152 > unrolled thread
| Started by | gazelle@shell.xmission.com (Kenny McCormack) |
|---|---|
| First post | 2026-01-05 07:19 +0000 |
| Last post | 2026-01-05 15:57 +0000 |
| Articles | 20 on this page of 209 — 21 participants |
Back to article view | Back to comp.lang.c
printf and time_t gazelle@shell.xmission.com (Kenny McCormack) - 2026-01-05 07:19 +0000
Re: printf and time_t Andrey Tarasevich <noone@noone.net> - 2026-01-05 00:17 -0800
Re: printf and time_t Michael S <already5chosen@yahoo.com> - 2026-01-05 10:51 +0200
Re: printf and time_t gazelle@shell.xmission.com (Kenny McCormack) - 2026-01-05 12:45 +0000
Re: printf and time_t Michael S <already5chosen@yahoo.com> - 2026-01-05 15:21 +0200
Re: printf and time_t gazelle@shell.xmission.com (Kenny McCormack) - 2026-01-05 13:49 +0000
Re: printf and time_t Michael S <already5chosen@yahoo.com> - 2026-01-05 16:47 +0200
Re: printf and time_t gazelle@shell.xmission.com (Kenny McCormack) - 2026-01-05 15:29 +0000
Re: printf and time_t bart <bc@freeuk.com> - 2026-01-05 13:22 +0000
Re: printf and time_t gazelle@shell.xmission.com (Kenny McCormack) - 2026-01-05 13:52 +0000
Re: printf and time_t Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-01-06 00:27 +0000
Re: printf and time_t Michael S <already5chosen@yahoo.com> - 2026-01-06 11:29 +0200
Re: printf and time_t James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-01-06 10:31 -0500
Re: printf and time_t Michael S <already5chosen@yahoo.com> - 2026-01-06 20:05 +0200
Re: printf and time_t scott@slp53.sl.home (Scott Lurndal) - 2026-01-06 18:16 +0000
Re: printf and time_t Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-01-07 05:06 -0800
Re: printf and time_t "James Russell Kuyper Jr." <jameskuyper@alumni.caltech.edu> - 2026-01-07 13:08 -0500
Re: printf and time_t Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-01-08 09:54 -0800
Re: printf and time_t Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-01-08 10:08 -0800
Re: printf and time_t scott@slp53.sl.home (Scott Lurndal) - 2026-01-08 18:36 +0000
Re: printf and time_t Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-01-08 13:05 -0800
Re: printf and time_t scott@slp53.sl.home (Scott Lurndal) - 2026-01-09 16:26 +0000
Re: printf and time_t Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-02-03 05:38 -0800
Re: printf and time_t "James Russell Kuyper Jr." <jameskuyper@alumni.caltech.edu> - 2026-01-10 22:40 -0500
Re: printf and time_t Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-01-06 16:29 -0800
Re: printf and time_t Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-01-06 17:14 -0800
Re: printf and time_t Michael S <already5chosen@yahoo.com> - 2026-01-07 14:01 +0200
Re: printf and time_t Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-01-07 04:28 -0800
Re: printf and time_t Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-02-03 22:03 -0800
Re: printf and time_t scott@slp53.sl.home (Scott Lurndal) - 2026-01-07 15:45 +0000
Re: printf and time_t Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-01-07 13:28 -0800
Re: printf and time_t Michael S <already5chosen@yahoo.com> - 2026-01-08 01:26 +0200
Re: printf and time_t Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-01-07 16:00 -0800
Re: printf and time_t Michael S <already5chosen@yahoo.com> - 2026-01-08 02:38 +0200
Re: printf and time_t Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-01-07 17:36 -0800
Re: printf and time_t Michael S <already5chosen@yahoo.com> - 2026-01-08 11:01 +0200
Re: printf and time_t "James Russell Kuyper Jr." <jameskuyper@alumni.caltech.edu> - 2026-01-08 19:31 -0500
Re: printf and time_t Michael S <already5chosen@yahoo.com> - 2026-01-09 14:18 +0200
Re: printf and time_t David Brown <david.brown@hesbynett.no> - 2026-01-09 13:49 +0100
Re: printf and time_t wij <wyniijj5@gmail.com> - 2026-01-10 00:17 +0800
Re: printf and time_t Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-01-09 11:27 -0800
Re: printf and time_t "James Russell Kuyper Jr." <jameskuyper@alumni.caltech.edu> - 2026-01-10 22:02 -0500
Re: printf and time_t Michael S <already5chosen@yahoo.com> - 2026-01-11 13:20 +0200
Re: printf and time_t Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-01-11 04:59 -0800
Re: printf and time_t Michael S <already5chosen@yahoo.com> - 2026-01-11 15:32 +0200
Re: printf and time_t David Brown <david.brown@hesbynett.no> - 2026-01-11 16:34 +0100
Re: printf and time_t Michael S <already5chosen@yahoo.com> - 2026-01-11 18:19 +0200
Re: printf and time_t David Brown <david.brown@hesbynett.no> - 2026-01-11 20:25 +0100
Re: printf and time_t Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-01-11 15:23 -0800
Re: printf and time_t Michael S <already5chosen@yahoo.com> - 2026-01-12 10:50 +0200
Re: printf and time_t Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-01-11 14:56 -0800
Re: printf and time_t Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-01-11 22:44 -0800
Re: printf and time_t Michael S <already5chosen@yahoo.com> - 2026-01-12 10:51 +0200
Re: printf and time_t David Brown <david.brown@hesbynett.no> - 2026-01-12 08:21 +0100
Re: printf and time_t Michael S <already5chosen@yahoo.com> - 2026-01-12 11:06 +0200
Re: printf and time_t David Brown <david.brown@hesbynett.no> - 2026-01-12 13:26 +0100
Re: printf and time_t Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-01-12 16:06 -0800
Re: printf and time_t David Brown <david.brown@hesbynett.no> - 2026-01-13 08:56 +0100
Re: printf and time_t Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-01-13 00:53 -0800
Re: printf and time_t David Brown <david.brown@hesbynett.no> - 2026-01-13 11:09 +0100
Re: printf and time_t Michael S <already5chosen@yahoo.com> - 2026-01-13 13:45 +0200
Re: printf and time_t David Brown <david.brown@hesbynett.no> - 2026-01-13 14:32 +0100
Re: printf and time_t Michael S <already5chosen@yahoo.com> - 2026-01-13 17:47 +0200
Re: printf and time_t Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-01-12 04:27 -0800
Re: printf and time_t David Brown <david.brown@hesbynett.no> - 2026-01-12 17:57 +0100
Re: printf and time_t Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-02-03 17:19 -0800
Re: printf and time_t Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-02-03 18:19 -0800
Re: printf and time_t Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-03-01 21:05 -0800
Re: printf and time_t "James Russell Kuyper Jr." <jameskuyper@alumni.caltech.edu> - 2026-01-13 21:24 -0500
Re: printf and time_t David Brown <david.brown@hesbynett.no> - 2026-01-14 09:26 +0100
Re: printf and time_t Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-01-14 14:53 -0800
Re: printf and time_t David Brown <david.brown@hesbynett.no> - 2026-01-15 08:29 +0100
Re: printf and time_t Michael S <already5chosen@yahoo.com> - 2026-01-14 11:03 +0200
Re: printf and time_t James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-01-14 22:19 -0500
Re: printf and time_t Michael S <already5chosen@yahoo.com> - 2026-01-15 11:02 +0200
Re: printf and time_t Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-01-11 11:58 -0800
Re: printf and time_t David Brown <david.brown@hesbynett.no> - 2026-01-12 08:28 +0100
Re: printf and time_t Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-01-11 11:51 -0800
Re: printf and time_t Michael S <already5chosen@yahoo.com> - 2026-01-11 23:51 +0200
Re: printf and time_t Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-01-11 22:47 -0800
Re: printf and time_t David Brown <david.brown@hesbynett.no> - 2026-01-12 08:34 +0100
Re: printf and time_t Michael S <already5chosen@yahoo.com> - 2026-01-12 11:24 +0200
Re: printf and time_t Michael S <already5chosen@yahoo.com> - 2026-01-12 10:34 +0200
Re: printf and time_t Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-02-03 07:47 -0800
Re: printf and time_t Bart <bc@freeuk.com> - 2026-02-03 19:51 +0000
Re: printf and time_t Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-02-04 06:22 -0800
Re: printf and time_t Bart <bc@freeuk.com> - 2026-02-04 16:44 +0000
Re: printf and time_t David Brown <david.brown@hesbynett.no> - 2026-02-04 18:12 +0100
Re: printf and time_t Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-02-04 18:48 +0100
Re: printf and time_t Bart <bc@freeuk.com> - 2026-02-04 18:11 +0000
Re: printf and time_t David Brown <david.brown@hesbynett.no> - 2026-02-04 21:09 +0100
Re: printf and time_t Bart <bc@freeuk.com> - 2026-02-04 20:42 +0000
Re: printf and time_t David Brown <david.brown@hesbynett.no> - 2026-02-05 12:41 +0100
Re: printf and time_t Bart <bc@freeuk.com> - 2026-02-05 17:42 +0000
Re: printf and time_t scott@slp53.sl.home (Scott Lurndal) - 2026-02-05 18:38 +0000
Re: printf and time_t Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-02-05 23:55 +0100
Re: printf and time_t Bart <bc@freeuk.com> - 2026-02-05 23:42 +0000
Re: printf and time_t Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-02-05 21:10 -0800
Re: printf and time_t Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-02-06 09:51 +0100
Re: printf and time_t Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-02-06 04:46 -0800
Re: printf and time_t Bart <bc@freeuk.com> - 2026-02-06 12:39 +0000
Re: printf and time_t Michael S <already5chosen@yahoo.com> - 2026-02-06 14:47 +0200
Re: printf and time_t Bart <bc@freeuk.com> - 2026-02-06 13:04 +0000
Re: printf and time_t Michael S <already5chosen@yahoo.com> - 2026-02-08 10:52 +0200
Re: printf and time_t Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-02-08 12:18 +0100
Re: printf and time_t Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-02-08 04:03 -0800
Re: printf and time_t antispam@fricas.org (Waldek Hebisch) - 2026-02-08 16:50 +0000
Re: printf and time_t David Brown <david.brown@hesbynett.no> - 2026-02-08 18:55 +0100
Re: printf and time_t Bart <bc@freeuk.com> - 2026-02-08 19:54 +0000
Re: printf and time_t David Brown <david.brown@hesbynett.no> - 2026-02-08 21:27 +0100
Re: printf and time_t antispam@fricas.org (Waldek Hebisch) - 2026-02-08 19:59 +0000
Re: printf and time_t Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-02-08 21:51 +0100
Re: printf and time_t Bart <bc@freeuk.com> - 2026-02-08 19:43 +0000
Re: printf and time_t David Brown <david.brown@hesbynett.no> - 2026-02-06 14:06 +0100
Re: printf and time_t Kaz Kylheku <046-301-5902@kylheku.com> - 2026-02-07 18:07 +0000
Re: printf and time_t Bart <bc@freeuk.com> - 2026-02-07 20:32 +0000
Re: printf and time_t antispam@fricas.org (Waldek Hebisch) - 2026-02-07 22:48 +0000
Re: printf and time_t Bart <bc@freeuk.com> - 2026-02-07 23:54 +0000
Re: printf and time_t antispam@fricas.org (Waldek Hebisch) - 2026-02-08 19:21 +0000
Re: printf and time_t Bart <bc@freeuk.com> - 2026-02-08 23:35 +0000
Re: printf and time_t antispam@fricas.org (Waldek Hebisch) - 2026-02-09 01:27 +0000
Re: printf and time_t Bart <bc@freeuk.com> - 2026-02-10 00:14 +0000
Re: printf and time_t antispam@fricas.org (Waldek Hebisch) - 2026-02-10 13:22 +0000
Re: printf and time_t antispam@fricas.org (Waldek Hebisch) - 2026-02-09 01:40 +0000
Re: printf and time_t Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-02-06 05:08 -0800
Re: printf and time_t Bart <bc@freeuk.com> - 2026-02-06 14:28 +0000
Re: printf and time_t Bart <bc@freeuk.com> - 2026-02-06 14:29 +0000
Re: printf and time_t Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-02-06 11:21 -0800
Re: printf and time_t Bart <bc@freeuk.com> - 2026-02-06 20:08 +0000
Re: printf and time_t Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-02-06 12:56 -0800
Re: printf and time_t scott@slp53.sl.home (Scott Lurndal) - 2026-02-06 14:35 +0000
Re: printf and time_t Kaz Kylheku <046-301-5902@kylheku.com> - 2026-02-07 17:55 +0000
Re: printf and time_t Bart <bc@freeuk.com> - 2026-02-07 20:51 +0000
Re: printf and time_t David Brown <david.brown@hesbynett.no> - 2026-02-06 12:27 +0100
Re: printf and time_t Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-02-05 11:05 -0800
Re: printf and time_t Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-02-06 02:59 -0800
Re: printf and time_t Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-02-06 04:49 -0800
Re: printf and time_t Bart <bc@freeuk.com> - 2026-02-06 13:05 +0000
Re: printf and time_t Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-02-17 23:11 -0800
Re: printf and time_t David Brown <david.brown@hesbynett.no> - 2026-02-06 12:42 +0100
Re: printf and time_t Michael S <already5chosen@yahoo.com> - 2026-02-04 22:48 +0200
Re: printf and time_t Michael S <already5chosen@yahoo.com> - 2026-02-04 22:57 +0200
Re: printf and time_t Bart <bc@freeuk.com> - 2026-02-04 23:24 +0000
Re: printf and time_t Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-02-04 16:04 -0800
Re: printf and time_t Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-02-04 15:39 -0800
Re: printf and time_t Bart <bc@freeuk.com> - 2026-02-04 23:52 +0000
Re: printf and time_t David Brown <david.brown@hesbynett.no> - 2026-02-05 12:51 +0100
Re: printf and time_t Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-02-05 11:22 -0800
Re: printf and time_t David Brown <david.brown@hesbynett.no> - 2026-02-06 12:46 +0100
Re: printf and time_t Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-02-06 02:25 -0800
Re: printf and time_t Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-02-03 14:43 -0800
Re: printf and time_t Bart <bc@freeuk.com> - 2026-02-03 23:06 +0000
Re: printf and time_t Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-02-03 15:33 -0800
Re: printf and time_t "James Russell Kuyper Jr." <jameskuyper@alumni.caltech.edu> - 2026-01-13 22:17 -0500
Re: printf and time_t Michael S <already5chosen@yahoo.com> - 2026-01-14 11:10 +0200
Re: printf and time_t James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-01-15 06:10 -0500
Re: printf and time_t Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-01-15 04:00 -0800
Re: printf and time_t James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-01-15 20:08 -0500
Re: printf and time_t Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-01-15 18:17 -0800
Re: printf and time_t David Brown <david.brown@hesbynett.no> - 2026-01-09 09:25 +0100
Re: printf and time_t David Brown <david.brown@hesbynett.no> - 2026-01-08 11:35 +0100
Re: printf and time_t James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-01-06 19:44 -0500
Re: printf and time_t bart <bc@freeuk.com> - 2026-01-07 01:14 +0000
Re: printf and time_t Michael S <already5chosen@yahoo.com> - 2026-01-07 13:41 +0200
Re: printf and time_t bart <bc@freeuk.com> - 2026-01-07 15:54 +0000
Re: printf and time_t Michael S <already5chosen@yahoo.com> - 2026-01-07 18:17 +0200
Re: printf and time_t "James Russell Kuyper Jr." <jameskuyper@alumni.caltech.edu> - 2026-01-07 12:45 -0500
Re: printf and time_t Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-01-07 20:31 +0000
Re: printf and time_t Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-01-07 13:32 -0800
Re: printf and time_t Michael S <already5chosen@yahoo.com> - 2026-01-08 01:29 +0200
Re: printf and time_t "James Russell Kuyper Jr." <jameskuyper@alumni.caltech.edu> - 2026-01-08 19:16 -0500
Re: printf and time_t David Brown <david.brown@hesbynett.no> - 2026-01-08 17:13 +0100
Re: printf and time_t Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2026-01-05 16:23 +0000
Re: printf and time_t gazelle@shell.xmission.com (Kenny McCormack) - 2026-01-05 16:34 +0000
Re: printf and time_t David Brown <david.brown@hesbynett.no> - 2026-01-05 17:34 +0100
Re: printf and time_t James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-01-05 13:11 -0500
Re: printf and time_t David Brown <david.brown@hesbynett.no> - 2026-01-05 19:28 +0100
Re: printf and time_t James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-01-05 14:00 -0500
Re: printf and time_t David Brown <david.brown@hesbynett.no> - 2026-01-05 20:38 +0100
Re: printf and time_t Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-01-05 14:41 -0800
Epoch seconds and linear count (was Re: printf and time_t) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-01-06 14:51 +0100
Re: printf and time_t Michael S <already5chosen@yahoo.com> - 2026-01-05 19:23 +0200
Re: printf and time_t Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-01-05 15:04 -0800
Re: printf and time_t Michael S <already5chosen@yahoo.com> - 2026-01-06 01:23 +0200
Re: printf and time_t Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-01-06 00:22 +0000
Re: printf and time_t James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-01-06 10:22 -0500
Re: printf and time_t Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2026-01-06 15:45 +0000
Re: printf and time_t Michael Bäuerle <michael.baeuerle@gmx.net> - 2026-01-06 17:00 +0100
Re: printf and time_t Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2026-01-06 16:08 +0000
Re: printf and time_t James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-01-06 11:19 -0500
Re: printf and time_t Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2026-01-06 16:18 +0000
Re: printf and time_t James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-01-05 13:14 -0500
Re: printf and time_t David Brown <david.brown@hesbynett.no> - 2026-01-05 11:32 +0100
Re: printf and time_t James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-01-05 07:37 -0500
Re: printf and time_t Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-01-06 00:30 +0000
Re: printf and time_t Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-01-05 20:00 -0800
Re: printf and time_t James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-01-05 07:50 -0500
Re: printf and time_t Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-01-07 05:02 -0800
Re: printf and time_t "James Russell Kuyper Jr." <jameskuyper@alumni.caltech.edu> - 2026-01-07 12:58 -0500
Re: printf and time_t Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-03-01 23:21 -0800
Re: printf and time_t Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-03-02 03:37 -0800
Re: printf and time_t James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-03-02 17:53 -0500
Re: printf and time_t Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-03-02 18:04 -0800
Re: printf and time_t Michael Sanders <porkchop@invalid.foo> - 2026-01-05 08:32 +0000
Re: printf and time_t Michael Sanders <porkchop@invalid.foo> - 2026-01-05 08:46 +0000
Re: printf and time_t highcrew <high.crew3868@fastmail.com> - 2026-01-05 12:48 +0100
Re: printf and time_t richard@cogsci.ed.ac.uk (Richard Tobin) - 2026-01-05 14:53 +0000
Re: printf and time_t gazelle@shell.xmission.com (Kenny McCormack) - 2026-01-05 15:36 +0000
Re: printf and time_t scott@slp53.sl.home (Scott Lurndal) - 2026-01-05 15:57 +0000
Page 10 of 11 — ← Prev page 1 … 8 9 [10] 11 Next page →
| From | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2026-01-06 14:51 +0100 |
| Subject | Epoch seconds and linear count (was Re: printf and time_t) |
| Message-ID | <10jj41o$3jb03$1@dont-email.me> |
| In reply to | #396191 |
On 2026-01-05 23:41, Keith Thompson wrote: > James Kuyper <jameskuyper@alumni.caltech.edu> writes: >> On 2026-01-05 11:34, David Brown wrote: >> ... >>> As I understand it, time_t is intended to be suitable for holding a >>> number of seconds ... >> >> The standard says nothing about that. >> >>> ... (it is used for that purpose in struct timespec). ... >> >> The standard says nothing to connect time_t to struct timespec. > > Yes, but also no. > > struct timespec contains at least the following members, in any order: > > time_t tv_sec; // whole seconds — ≥ 0 > long tv_nsec; // nanoseconds — [0, 999999999] > > But a footnote says: > > The tv_sec member is a linear count of seconds and may not have > the normal semantics of a time_t. > > This makes for a simpler implementation *if* the time_t value > returned by time(), and operated on by difftime(), mktime(), ctime(), > gmtime(), and localtime(), happens to hold a linear count of seconds > (as it does on most systems). Hmm.. - my post is not aiming in your direction but this statement made me curious. - A linear count (in the sense of TAI) should then show a difference between civil time and [TAI-]seconds since Epoch. A quick test shows that there's no leap seconds considered. So no "linear count" (in the sense of TAI). Leap seconds are disregarded in the "linear" seconds count. > > It's odd that time_t is used for two potentially very different > purposes, one as a member of struct timespec and another as used > in all other contexts. Semantically it might have made sense if its used for differentiating internal TAI (time_t) from UTC or local time on the UI (struct tm). Janis > And I would guess that a lot of code that > uses struct timespec *assumes* that its time_t member has the same > semantics value returned by time(NULL). > > For example, as I write this the time is 2026-01-05 22:32:57.881 UTC. > The corresponding value returned by time() is 1767652377 (seconds > since the 1970 epoch, no milliseconds). An implementation could > represent the current time (the value returned by time(NULL) as a > 64-bit integer with the value 20260105223257881. But timespec_get() > would still have to set the tv_sec member to 1767652377. > > It might have been cleaner either to require that time_t represents a > count of seconds, or to use a type other than time_t for the tv_sec > member of struct timespec. > > I know there are systems that use something other than seconds > since 1970 in the underlying time representation, but are there any > C implementations that don't use seconds since 1970? (POSIX and > Windows both specify that.) >
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2026-01-05 19:23 +0200 |
| Message-ID | <20260105192351.00001903@yahoo.com> |
| In reply to | #396180 |
On Mon, 5 Jan 2026 16:23:09 -0000 (UTC) Lew Pitcher <lew.pitcher@digitalfreehold.ca> wrote: > On Mon, 05 Jan 2026 10:51:38 +0200, Michael S wrote: > > > On Mon, 5 Jan 2026 00:17:07 -0800 > > Andrey Tarasevich <noone@noone.net> wrote: > > > >> On Sun 1/4/2026 11:19 PM, Kenny McCormack wrote: > >> > The question is: How can you reliably printf() a time_t value? > >> > What conversion spec should you use? > >> > >> You can't. As far as the language is concerned, `time_t` is > >> intended to be an opaque type. It has to be a real type, so it is > >> either an integer of a plain floating-point type. But other than > >> that nothing is known about it. There's really no point in > >> printing it. > >> > >> If you still want to, you can do it in some implementation-specific > >> way. Which still immediately means that you can't do it "reliably", > >> if I understand what you mean correctly. > >> > > > > I can't think about situation in which casting time_t value to 'long > > long' can go wrong. > > As Andrey pointed out, time_t can resolve to a floatingpoint type, > so, "long long" would go wrong if the implementation typedefs it to > float, or > double, or > long double. > Reading literally what you wrote makes no sense, so I assume that you meant that 'it' above constitutes time_t rather than 'long long'. The rest of the post assumes 64-bit 'long long'. 'typedef float time_t' where float==IEEE binary32 is a bad idea, because you lose your 1sec resolution after 7 months. I.e. with Unix epoch you lost it a year or two before Ritchi finished his first C compiler. 'typedef double time_t' means that you lost 1 sec resolution ~3 orders of magnitude before you got a chance to overflow 'long long'. Only in case of 'typedef long double time_t' there is a chance that overflow happens before resolution is lost. But barely so for 80-bit long double format prevalent on i386/AMD64 computers.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2026-01-05 15:04 -0800 |
| Message-ID | <87pl7n3bm1.fsf@example.invalid> |
| In reply to | #396183 |
Michael S <already5chosen@yahoo.com> writes:
> On Mon, 5 Jan 2026 16:23:09 -0000 (UTC)
> Lew Pitcher <lew.pitcher@digitalfreehold.ca> wrote:
[...]
>> As Andrey pointed out, time_t can resolve to a floatingpoint type,
>> so, "long long" would go wrong if the implementation typedefs it to
>> float, or
>> double, or
>> long double.
>
> Reading literally what you wrote makes no sense, so I assume that you
> meant that 'it' above constitutes time_t rather than 'long long'.
>
> The rest of the post assumes 64-bit 'long long'.
> 'typedef float time_t' where float==IEEE binary32 is a bad idea, because
> you lose your 1sec resolution after 7 months. I.e. with Unix epoch you
> lost it a year or two before Ritchi finished his first C compiler.
> 'typedef double time_t' means that you lost 1 sec resolution ~3
> orders of magnitude before you got a chance to overflow 'long long'.
>
> Only in case of 'typedef long double time_t' there is a chance that
> overflow happens before resolution is lost. But barely so for 80-bit
> long double format prevalent on i386/AMD64 computers.
Assuming IEEE floating-point, and assuming time_t represents seconds
since the usual 1970 epoch, the current resolution of a 64-bit
floating-point time_t would be about 238 nanoseconds. It has
that same resolution for any time from 2004-01-10 to 2038-01-18.
(The resolution doubles when the number of seconds since 1970
exceeds a power of 2.) The resolution doesn't reach one second
until 142715360-12-05 (that's a Friday if we're still using the
same calendar).
I don't suggest that using type double for time_t would be a good
idea, and in fact POSIX requires time_t to be an integer type.
(I think Windows does as well, but the documentation is less clear,
or perhaps I'm missing something.)
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2026-01-06 01:23 +0200 |
| Message-ID | <20260106012347.000075a0@yahoo.com> |
| In reply to | #396192 |
On Mon, 05 Jan 2026 15:04:22 -0800 Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote: > (I think Windows does as well, but the documentation is less clear, > or perhaps I'm missing something.) > On Windows time_t belongs to implementation of C language rather than to OS API/ABI. So, Windows OS can't have any requirements for time_t beyond requirement of C Standard. If we are talking specifically about Microsoft's implementation then it is easy to observe that time_t is 64-bit integer by default and 32-bit integer when user defines macro _USE_32BIT_TIME_T
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D’Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2026-01-06 00:22 +0000 |
| Message-ID | <10jhkk5$3c9r2$2@nntp.eternal-september.org> |
| In reply to | #396180 |
On Mon, 5 Jan 2026 16:23:09 -0000 (UTC), Lew Pitcher wrote: > As Andrey pointed out, time_t can resolve to a floatingpoint type, POSIX says time_t is an integer type <https://manpages.debian.org/time_t(3type)>.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2026-01-06 10:22 -0500 |
| Message-ID | <10jj9bk$3jbe4$1@dont-email.me> |
| In reply to | #396194 |
On 2026-01-05 19:22, Lawrence D’Oliveiro wrote: > On Mon, 5 Jan 2026 16:23:09 -0000 (UTC), Lew Pitcher wrote: > >> As Andrey pointed out, time_t can resolve to a floatingpoint type, > > POSIX says time_t is an integer type > <https://manpages.debian.org/time_t(3type)>. Which means that implementations where time_t has a floating point type cannot comply with POSIX; many implementations fail to do so.
[toc] | [prev] | [next] | [standalone]
| From | Lew Pitcher <lew.pitcher@digitalfreehold.ca> |
|---|---|
| Date | 2026-01-06 15:45 +0000 |
| Message-ID | <10jjan1$3r7av$1@dont-email.me> |
| In reply to | #396212 |
On Tue, 06 Jan 2026 10:22:28 -0500, James Kuyper wrote: > On 2026-01-05 19:22, Lawrence D’Oliveiro wrote: >> On Mon, 5 Jan 2026 16:23:09 -0000 (UTC), Lew Pitcher wrote: >> >>> As Andrey pointed out, time_t can resolve to a floatingpoint type, >> >> POSIX says time_t is an integer type Actually, POSIX does not say that. >> <https://manpages.debian.org/time_t(3type)>. The Debian manpages do not necessarily represent current POSIX standards. The current online POSIX standards pages say that, among others, time_t "shall be defined as arithmetic types of an appropriate length" (https://pubs.opengroup.org/onlinepubs/9799919799/basedefs/sys_types.h.html) The current POSIX definition of time(2) does mention integer values, but only as historic reference, and refers to the definition of time_t in <time.h> (https://pubs.opengroup.org/onlinepubs/9799919799/functions/time.html) The current POSIX definition <time.h> says that the <time.h> header "shall define the clock_t, size_t, time_t, types as described in <sys/types.h>." (https://pubs.opengroup.org/onlinepubs/9799919799/basedefs/time.h.html) And, the current POSIX definition of the <sys/types.h> header says, as above, that time_t shall be defined as an arithmetic type. > Which means that implementations where time_t has a floating point type > cannot comply with POSIX; many implementations fail to do so. In practice, the POSIX specs likely means that time_t will represent an integer of some size, but the POSIX specs do /not/ say that time_t /must/ be an integer. -- Lew Pitcher "In Skills We Trust" Not LLM output - I'm just like this.
[toc] | [prev] | [next] | [standalone]
| From | Michael Bäuerle <michael.baeuerle@gmx.net> |
|---|---|
| Date | 2026-01-06 17:00 +0100 |
| Message-ID | <AABpXTGrU5AAAAp3.A3.flnews@WStation7.micha.freeshell.org> |
| In reply to | #396215 |
Lew Pitcher wrote: > On Tue, 06 Jan 2026 10:22:28 -0500, James Kuyper wrote: > > On 2026-01-05 19:22, Lawrence D’Oliveiro wrote: > > > On Mon, 5 Jan 2026 16:23:09 -0000 (UTC), Lew Pitcher wrote: > > > > > > > > As Andrey pointed out, time_t can resolve to a floatingpoint type, > > > > > > POSIX says time_t is an integer type > > Actually, POSIX does not say that. > > > > <https://manpages.debian.org/time_t(3type)>. > > The Debian manpages do not necessarily represent current POSIX standards. > > The current online POSIX standards pages say that, among others, time_t > "shall be defined as arithmetic types of an appropriate length" > (https://pubs.opengroup.org/onlinepubs/9799919799/basedefs/sys_types.h.html) Looks like you looked at an old version. Currently there is: | | [CX] time_t shall be an integer type with a width (see <stdint.h>) of at least 64 bits. | [...] | Austin Group Defect 1462 is applied, changing time_t to have a width of at least 64 bits. It refers to this issue: <https://www.austingroupbugs.net/view.php?id=1462>
[toc] | [prev] | [next] | [standalone]
| From | Lew Pitcher <lew.pitcher@digitalfreehold.ca> |
|---|---|
| Date | 2026-01-06 16:08 +0000 |
| Message-ID | <10jjc2c$3r7av$2@dont-email.me> |
| In reply to | #396217 |
On Tue, 06 Jan 2026 17:00:43 +0100, Michael Bäuerle wrote: > Lew Pitcher wrote: >> On Tue, 06 Jan 2026 10:22:28 -0500, James Kuyper wrote: >> > On 2026-01-05 19:22, Lawrence D’Oliveiro wrote: >> > > On Mon, 5 Jan 2026 16:23:09 -0000 (UTC), Lew Pitcher wrote: >> > > > >> > > > As Andrey pointed out, time_t can resolve to a floatingpoint type, >> > > >> > > POSIX says time_t is an integer type >> >> Actually, POSIX does not say that. >> >> > > <https://manpages.debian.org/time_t(3type)>. >> >> The Debian manpages do not necessarily represent current POSIX standards. >> >> The current online POSIX standards pages say that, among others, time_t >> "shall be defined as arithmetic types of an appropriate length" >> (https://pubs.opengroup.org/onlinepubs/9799919799/basedefs/sys_types.h.html) > > Looks like you looked at an old version. Currently there is: > | > | [CX] time_t shall be an integer type with a width (see <stdint.h>) of at least 64 bits. > | [...] > | Austin Group Defect 1462 is applied, changing time_t to have a width of at least 64 bits. Do you have a URL reference for this? I got my POSIX references direct from the Open Group's "current standards" links. The time(2), <time.h> and <sys/types.h> webpages are all headed: The Open Group Base Specifications Issue 8 IEEE Std 1003.1-2024 Perhaps they have not yet applied the defect remediation to the online reference. > It refers to this issue: > <https://www.austingroupbugs.net/view.php?id=1462> -- Lew Pitcher "In Skills We Trust" Not LLM output - I'm just like this.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2026-01-06 11:19 -0500 |
| Message-ID | <10jjcm2$3jbe4$4@dont-email.me> |
| In reply to | #396218 |
On 2026-01-06 11:08, Lew Pitcher wrote: > On Tue, 06 Jan 2026 17:00:43 +0100, Michael Bäuerle wrote: > >> Lew Pitcher wrote: ... >>> The current online POSIX standards pages say that, among others, time_t >>> "shall be defined as arithmetic types of an appropriate length" >>> (https://pubs.opengroup.org/onlinepubs/9799919799/basedefs/sys_types.h.html) I followed the link Lew provided, and found precisely the text quoted by Michael: >> Looks like you looked at an old version. Currently there is: >> | >> | [CX] time_t shall be an integer type with a width (see <stdint.h>) of at least 64 bits. >> | [...] >> | Austin Group Defect 1462 is applied, changing time_t to have a width of at least 64 bits. The part where it says that time_t shall be an integer type is in a separate section titled "Additionally", 27 lines of text after it says "shall be defined as arithmetic types ...". > Do you have a URL reference for this? I got my POSIX references direct from the Open Group's > "current standards" links. The time(2), <time.h> and <sys/types.h> webpages are all > headed: > The Open Group Base Specifications Issue 8 > IEEE Std 1003.1-2024 > > Perhaps they have not yet applied the defect remediation to the online reference.
[toc] | [prev] | [next] | [standalone]
| From | Lew Pitcher <lew.pitcher@digitalfreehold.ca> |
|---|---|
| Date | 2026-01-06 16:18 +0000 |
| Message-ID | <10jjckv$3r7av$3@dont-email.me> |
| In reply to | #396217 |
On Tue, 06 Jan 2026 17:00:43 +0100, Michael Bäuerle wrote: > Lew Pitcher wrote: >> On Tue, 06 Jan 2026 10:22:28 -0500, James Kuyper wrote: >> > On 2026-01-05 19:22, Lawrence D’Oliveiro wrote: >> > > On Mon, 5 Jan 2026 16:23:09 -0000 (UTC), Lew Pitcher wrote: >> > > > >> > > > As Andrey pointed out, time_t can resolve to a floatingpoint type, >> > > >> > > POSIX says time_t is an integer type >> >> Actually, POSIX does not say that. >> >> > > <https://manpages.debian.org/time_t(3type)>. >> >> The Debian manpages do not necessarily represent current POSIX standards. >> >> The current online POSIX standards pages say that, among others, time_t >> "shall be defined as arithmetic types of an appropriate length" >> (https://pubs.opengroup.org/onlinepubs/9799919799/basedefs/sys_types.h.html) > > Looks like you looked at an old version. Currently there is: > | > | [CX] time_t shall be an integer type with a width (see <stdint.h>) of at least 64 bits. > | [...] > | Austin Group Defect 1462 is applied, changing time_t to have a width of at least 64 bits. > > It refers to this issue: > <https://www.austingroupbugs.net/view.php?id=1462> Ok, I've looked at the bugreport, and it looks like they /have/ updated the online documentation, as per the bug resolution. I missed the crucial part in <sys/types.h> that you quoted. Sorry. I'll be quiet now. -- Lew Pitcher "In Skills We Trust" Not LLM output - I'm just like this.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2026-01-05 13:14 -0500 |
| Message-ID | <10jgv1k$2rp4s$4@nntp.eternal-september.org> |
| In reply to | #396161 |
On 2026-01-05 03:51, Michael S wrote: .... > I can't think about situation in which casting time_t value to 'long > long' can go wrong. If time_t is a floating point type, or even an extended integer type with a greater range than long long, or even simply unsigned long long, the value could be too large to store in long long, in which case the conversion has undefined behavior. If time_t is a flaoting point type, another problem is that the conversion will discard the fractional part of the value. Depending upon how time_t is scaled, that might result is a large error.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-01-05 11:32 +0100 |
| Message-ID | <10jg3vi$2o69f$1@dont-email.me> |
| In reply to | #396156 |
On 05/01/2026 09:17, Andrey Tarasevich wrote: > On Sun 1/4/2026 11:19 PM, Kenny McCormack wrote: >> The question is: How can you reliably printf() a time_t value? >> What conversion spec should you use? > > You can't. As far as the language is concerned, `time_t` is intended to > be an opaque type. It has to be a real type, so it is either an integer > of a plain floating-point type. But other than that nothing is known > about it. There's really no point in printing it. > > If you still want to, you can do it in some implementation-specific way. > Which still immediately means that you can't do it "reliably", if I > understand what you mean correctly. > Does being a "real type" imply that "time_t" is always an alias for a standard integer type or standard floating point type? If so, then a _Generic macro might be a solution here. If it could be an extended integer type (or a _BitInt type in C23 :-) ), or some other scalar type, then a _Generic macro will not cover all hypothetically possible cases. But it might still cover all practical cases of interest to the OP.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2026-01-05 07:37 -0500 |
| Message-ID | <10jgb9j$2rp4s$1@nntp.eternal-september.org> |
| In reply to | #396162 |
On 2026-01-05 05:32, David Brown wrote: ... > Does being a "real type" imply that "time_t" is always an alias for a > standard integer type or standard floating point type? No, real types include integer types, which in turn includes the signed and unsigned integer types (6.2.5p22). The signed integer types include the extended signed integer types (6.2.5p6), and the unsigned integer types include the extended unsigned integer types (6.2.5p8).
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D’Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2026-01-06 00:30 +0000 |
| Message-ID | <10jhl3t$3c9r2$4@nntp.eternal-september.org> |
| In reply to | #396167 |
On Mon, 5 Jan 2026 07:37:07 -0500, James Kuyper wrote: > On 2026-01-05 05:32, David Brown wrote: > ... >> Does being a "real type" imply that "time_t" is always an alias for >> a standard integer type or standard floating point type? > > No, real types include integer types, which in turn includes the > signed and unsigned integer types (6.2.5p22). The signed integer > types include the extended signed integer types (6.2.5p6), and the > unsigned integer types include the extended unsigned integer types > (6.2.5p8). They could have said “numeric types” to avoid confusion with the mathematical usage ...
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2026-01-05 20:00 -0800 |
| Message-ID | <87ldib2xvx.fsf@example.invalid> |
| In reply to | #396196 |
Lawrence D’Oliveiro <ldo@nz.invalid> writes:
> On Mon, 5 Jan 2026 07:37:07 -0500, James Kuyper wrote:
>> On 2026-01-05 05:32, David Brown wrote:
>> ...
>>> Does being a "real type" imply that "time_t" is always an alias for
>>> a standard integer type or standard floating point type?
>>
>> No, real types include integer types, which in turn includes the
>> signed and unsigned integer types (6.2.5p22). The signed integer
>> types include the extended signed integer types (6.2.5p6), and the
>> unsigned integer types include the extended unsigned integer types
>> (6.2.5p8).
>
> They could have said “numeric types” to avoid confusion with the
> mathematical usage ...
No, complex types are numeric types (or arithmetic types in C terms).
And in mathematical terms, both integer types and real floating types
represent subsets of the mathematical real numbers (plus nans and
infinities for the real floating types).
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2026-01-05 07:50 -0500 |
| Message-ID | <10jgc2t$2rp4s$2@nntp.eternal-september.org> |
| In reply to | #396156 |
On 2026-01-05 03:17, Andrey Tarasevich wrote:
> On Sun 1/4/2026 11:19 PM, Kenny McCormack wrote:
>> The question is: How can you reliably printf() a time_t value?
>> What conversion spec should you use?
>
> You can't. As far as the language is concerned, `time_t` is intended to
> be an opaque type. It has to be a real type, ...
In C99, it was only required to be an arithmetic type. I pointed out
that this would permit it to be, for example, double _Imaginary. I like
to think that my comment may have been responsible for the fact that
C2011 specified that it must be real.
> ... so it is either an integer
> of a plain floating-point type. But other than that nothing is known
> about it. There's really no point in printing it.
>
> If you still want to, you can do it in some implementation-specific way.
> Which still immediately means that you can't do it "reliably", if I
> understand what you mean correctly.
if(1/(time_t)2)
{ // time_t is a floating point type)
prrintf("%lg", (long double)t);
}
else if(0 < (time_t)-1)
{ // time_t is an unsigned integer type
printf("%ju", (uintmax_t)t);
}
else // time_t is a signed integer type
printf("%jd", (intmax_t)t);
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2026-01-07 05:02 -0800 |
| Message-ID | <86o6n5pocw.fsf@linuxsc.com> |
| In reply to | #396169 |
James Kuyper <jameskuyper@alumni.caltech.edu> writes: > On 2026-01-05 03:17, Andrey Tarasevich wrote: > >> On Sun 1/4/2026 11:19 PM, Kenny McCormack wrote: >> >>> The question is: How can you reliably printf() a time_t value? >>> What conversion spec should you use? >> >> You can't. As far as the language is concerned, `time_t` is intended >> to be an opaque type. It has to be a real type, ... > > In C99, it was only required to be an arithmetic type. I pointed out > that this would permit it to be, for example, double _Imaginary. [...] It's hard to imagine how time_t being an imaginary type could provide the semantics described in the C standard for time_t.
[toc] | [prev] | [next] | [standalone]
| From | "James Russell Kuyper Jr." <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2026-01-07 12:58 -0500 |
| Message-ID | <10jm6se$r6nl$1@dont-email.me> |
| In reply to | #396261 |
On 2026-01-07 08:02, Tim Rentsch wrote: > James Kuyper <jameskuyper@alumni.caltech.edu> writes: > >> On 2026-01-05 03:17, Andrey Tarasevich wrote: ... >>> You can't. As far as the language is concerned, `time_t` is intended >>> to be an opaque type. It has to be a real type, ... >> >> In C99, it was only required to be an arithmetic type. I pointed out >> that this would permit it to be, for example, double _Imaginary. [...] > > It's hard to imagine how time_t being an imaginary type could > provide the semantics described in the C standard for time_t. You'll need to elaborate on that. time_t is an opaque type which could, on one implementation, have been long double. Another implementation could have stored the same value as the imaginary component of _Imaginary long double, and could work with that value the same way as the first one. It would be a perverse implementation, but I see no serious obstacles to creating such an implementation. A good optimizer might even generate exactly the same machine code from C source code for the two implementations.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2026-03-01 23:21 -0800 |
| Message-ID | <864imyg0im.fsf@linuxsc.com> |
| In reply to | #396277 |
"James Russell Kuyper Jr." <jameskuyper@alumni.caltech.edu> writes: > On 2026-01-07 08:02, Tim Rentsch wrote: > >> James Kuyper <jameskuyper@alumni.caltech.edu> writes: >> >>> On 2026-01-05 03:17, Andrey Tarasevich wrote: > > ... > >>>> You can't. As far as the language is concerned, `time_t` is intended >>>> to be an opaque type. It has to be a real type, ... >>> >>> In C99, it was only required to be an arithmetic type. I pointed out >>> that this would permit it to be, for example, double _Imaginary. [...] >> >> It's hard to imagine how time_t being an imaginary type could >> provide the semantics described in the C standard for time_t. > > You'll need to elaborate on that. time_t is an opaque type which > could, on one implementation, have been long double. Another > implementation could have stored the same value as the imaginary > component of _Imaginary long double, and could work with that value > the same way as the first one. [...] The C standard doesn't say that time_t is an opaque type. What it does say (in the C99 standard) is that it is an arithmetic type capable of representing times, and that the range and precision of those times are implementation defined. The idea that time_t is an opaque type doesn't mesh with that description, nor does it mesh with historical usage that predates even the earliest work on the original (ANSI) C standard. Even if we don't know the range and precision, we expect to be able to operate on time values with standard arithmetic operators, but that doesn't work for complex or imaginary values because of the rules for relational operators. Besides all of that, _Imaginary types don't satisify the condition for time_t to be an arithmetic type. Annex G says the imaginary types are floating types, but in C99 Annex G is informative, not normative.
[toc] | [prev] | [next] | [standalone]
Page 10 of 11 — ← Prev page 1 … 8 9 [10] 11 Next page →
Back to top | Article view | comp.lang.c
csiph-web