One thing Unix (and its POSIX-based successors) did differently from most other OSes was its system clock was not set to local time, but to UTC (and to GMT, before UTC). This seems pointless if you are accustomed to only dealing with one time zone, but it turned out to be a very elegant idea, that simplified a lot of date/time headaches.
Was Unix the first to come up with this idea? Did some other OS (Multics, perhaps?) pioneer this convention first?
But it means I then have to configure Windows to do the same on my
laptops that dual boot. And that works ok, surprisingly for microsoft.
On Wed, 30 Oct 2024 02:48:39 -0000 (UTC), Peter Dean wrote:
But it means I then have to configure Windows to do the same on my
laptops that dual boot. And that works ok, surprisingly for microsoft.
I didn’t know Windows had added that option.
Note that what you’re talking about is the hardware clock, not the OS clock per se. Linux, for example, typically only reads the hardware clock once at boot time, and writes the current time back to it once at system shutdown. It can be configured, via /etc/adjtime, to read/write the
hardware clock in either UTC or local time, the latter for compatibility with other OSes like Windows; this doesn’t affect the clock the system maintains while it’s running, which is always in UTC.
Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
One thing Unix (and its POSIX-based successors) did differently from most >> other OSes was its system clock was not set to local time, but to UTC (and >> to GMT, before UTC). This seems pointless if you are accustomed to only
dealing with one time zone, but it turned out to be a very elegant idea,
that simplified a lot of date/time headaches.
Was Unix the first to come up with this idea? Did some other OS (Multics, >> perhaps?) pioneer this convention first?
Sorry, I don't know the answer to your question.
But it means I then have to configure Windows to do the same on my laptops that dual boot. And that works ok, surprisingly for microsoft.
One thing Unix (and its POSIX-based successors) did differently from most other OSes was its system clock was not set to local time, but to UTC (and to GMT, before UTC). This seems pointless if you are accustomed to only dealing with one time zone, but it turned out to be a very elegant idea, that simplified a lot of date/time headaches.
Was Unix the first to come up with this idea? Did some other OS (Multics, perhaps?) pioneer this convention first?
Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
One thing Unix (and its POSIX-based successors) did differently from most
other OSes was its system clock was not set to local time, but to UTC (and >> to GMT, before UTC). This seems pointless if you are accustomed to only
dealing with one time zone, but it turned out to be a very elegant idea,
that simplified a lot of date/time headaches.
Was Unix the first to come up with this idea? Did some other OS (Multics,
perhaps?) pioneer this convention first?
Sorry, I don't know the answer to your question.
But it means I then have to configure Windows to do the same on my laptops that dual boot. And that works ok, surprisingly for microsoft.
One thing Unix (and its POSIX-based successors) did differently from most other OSes was its system clock was not set to local time, but to UTC (and
to GMT, before UTC). This seems pointless if you are accustomed to only dealing with one time zone, but it turned out to be a very elegant idea,
that simplified a lot of date/time headaches.
Was Unix the first to come up with this idea? Did some other OS (Multics, perhaps?) pioneer this convention first?
Peter Dean wrote this copyrighted missive and expects royalties:
But it means I then have to configure Windows to do the same on my laptops >> that dual boot. And that works ok, surprisingly for microsoft.
I recently set up a dual boot on a mini PC. That was one "fix". Another was changing the Caps Lock to Ctrl [I did that on my work laptop, only to find that
the Corp changed it back].
Also add Git Bash and MSYS2 to get nicer shells, git, ssh, etc.
And install VLC to listen to SomaFM. (On Linux I use MPD).
One thing Unix (and its POSIX-based successors) did differently from most other OSes was its system clock was not set to local time, but to UTC (and to GMT, before UTC). This seems pointless if you are accustomed to only dealing with one time zone, but it turned out to be a very elegant idea, that simplified a lot of date/time headaches.
Was Unix the first to come up with this idea? Did some other OS (Multics, perhaps?) pioneer this convention first?
the 370 hardware tod clock was spec'ed GMT since the start of the
century.
On the original IBM PC and most clones you had to type the time and date
on every boot.
Lawrence D'Oliveiro <ldo@nz.invalid> writes:
One thing Unix (and its POSIX-based successors) did differently from most >> other OSes was its system clock was not set to local time, but to UTC (and >> to GMT, before UTC). This seems pointless if you are accustomed to only
dealing with one time zone, but it turned out to be a very elegant idea,
that simplified a lot of date/time headaches.
Was Unix the first to come up with this idea? Did some other OS (Multics, >> perhaps?) pioneer this convention first?
On Wed, 30 Oct 2024 14:11:07 +0100, Carlos E.R. wrote:
On the original IBM PC and most clones you had to type the time and date
on every boot.
Funnily enough, you still have to do that on a Raspberry Pi. Because that >product has such a low cost, even a battery-backed-up clock would add too >much to it.
Lawrence D'Oliveiro <ldo@nz.invalid> writes:
On Wed, 30 Oct 2024 14:11:07 +0100, Carlos E.R. wrote:
On the original IBM PC and most clones you had to type the time and
date on every boot.
Funnily enough, you still have to do that on a Raspberry Pi. Because
that product has such a low cost, even a battery-backed-up clock would
add too much to it.
Not particularly funny, nor true. Several i2c RTC are available for
rPI for less than a sawbuck. If network connected, NTP is just a packet away.
That is the strength of the rPI, configurability and extension.
Interesting, because Bitsavers has this paper from 1986 wherein it is recommended that an IBM mainframe be rebooted after a change in the daylight-saving setting, just to be safe.
Page 88.5 of this manual says the Multics clock returned the number of microseconds since 00:00 GMT on 1 Jan 1901.
https://bitsavers.org/pdf/honeywell/large_systems/multics/AG93-05A_subrtns_Nov86.pdf
Lawrence D'Oliveiro <ldo@nz.invalid> writes:
On Wed, 30 Oct 2024 14:11:07 +0100, Carlos E.R. wrote:
On the original IBM PC and most clones you had to type the time and date >>> on every boot.
Funnily enough, you still have to do that on a Raspberry Pi. Because that >>product has such a low cost, even a battery-backed-up clock would add too >>much to it.
Not particularly funny, nor true. Several i2c RTC are available for rPI for less than a sawbuck. If network connected, NTP is just a packet away.
That is the strength of the rPI, configurability and extension.
| Sysop: | Tetrazocine |
|---|---|
| Location: | Melbourne, VIC, Australia |
| Users: | 4 |
| Nodes: | 8 (0 / 8) |
| Uptime: | 59:01:09 |
| Calls: | 65 |
| Files: | 21,500 |
| Messages: | 73,556 |