Discussion:
Who First Thought Of Using GMT/UTC For System Clock?
(too old to reply)
Lawrence D'Oliveiro
2024-10-30 00:00:55 UTC
Permalink
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
2024-10-30 02:48:39 UTC
Permalink
Post by Lawrence D'Oliveiro
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.
Lawrence D'Oliveiro
2024-10-30 03:11:29 UTC
Permalink
Post by Peter Dean
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.
Peter Dean
2024-10-30 03:58:15 UTC
Permalink
Post by Lawrence D'Oliveiro
Post by Peter Dean
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.
You are correct that it's issues with the harware clock flipping back and
forth.

I'm mainly on arch so here's a link to their wiki.
https://wiki.archlinux.org/title/System_time#UTC_in_Microsoft_Windows
Chris Ahlstrom
2024-10-30 11:07:56 UTC
Permalink
Post by Peter Dean
Post by Lawrence D'Oliveiro
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.
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).
--
"It is easier to fight for principles than to live up to them."
-- Alfred Adler
Peter Dean
2024-10-30 14:48:59 UTC
Permalink
Post by Chris Ahlstrom
Post by Peter Dean
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.
makes an arch user feel at home
Post by Chris Ahlstrom
And install VLC to listen to SomaFM. (On Linux I use MPD).
and vim, strawberry perl, tcl, qgis, postgis, etc.

microsoft just doesn't include much that you need to get your job done. The
useful things come from *nix.
Carlos E.R.
2024-10-30 13:11:07 UTC
Permalink
Post by Peter Dean
Post by Lawrence D'Oliveiro
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.
That's a relatively recent change. I think it happened on Windows 7 or
10. Before that, Windows by default worked with local time only, which
they inherited from MsDOS.

On the original IBM PC and most clones you had to type the time and date
on every boot. Somebody invented an add on card with a permanent clock
running on a small battery, and which had a small CMOS ram. Eventually,
that card was made into every motherboard. That small ram was then used
to hold the bios configuration.
--
Cheers, Carlos.
Lawrence D'Oliveiro
2024-10-30 20:54:38 UTC
Permalink
Post by Carlos E.R.
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.
Bob Eager
2024-10-30 22:26:54 UTC
Permalink
Post by Lawrence D'Oliveiro
Post by Carlos E.R.
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.
Lawrence is wrong yet again. Later Pis can have a battery added to them.
About 5 pounds here in the UK.
--
Using UNIX since v6 (1975)...

Use the BIG mirror service in the UK:
http://www.mirrorservice.org
Jim Jackson
2024-11-08 17:21:51 UTC
Permalink
Post by Lawrence D'Oliveiro
Post by Carlos E.R.
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.
Indeed I fully agree - but the bare board (4 or less, I don't know about
the 5) doesn't have a realtime clock and that is all he is saying. There
was quite a bit of discussion about that in the rpi forums in the early
days.

I have several pi's and the only one that has an i2c RTC addon connected
is the home server which acts, among another things, as an NTP server
for the other RPi's and other machines.

Carlos E.R.
2024-10-30 13:14:51 UTC
Permalink
Post by Lawrence D'Oliveiro
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?
Maybe from working with the USA military?
Or from very early setting computers with remote terminals that could be
on another time zone. They would soon learn that it was a nightmare to
hold to local time.
--
Cheers, Carlos.
Lynn Wheeler
2024-10-30 19:07:03 UTC
Permalink
Post by Lawrence D'Oliveiro
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?
joined ibm science center not long before internal 370 spec. the 370
hardware tod clock was spec'ed GMT since the start of the century. spent
a couple months in discussions about whether start of the century was
1/1/1900 or 1/1/1901 (technically it is 1/1/1901, but lots of places
were setting it to start 1/1/1900, and then found some setting it with
start 1/1/1970). the other big discussion was how to handle "leap
seconds". They finally had to further clarify the public published spec.

trivia: some of the MIT CTSS/7094 people went to project mac for multics
on the 5th flr, others went to the ibm science center on the 4th flr.

from eearly 370 principles of operation.

Thus, the operator can enable the setting of all clocks in the
configuration by using the switch ,of any CPU in the configuration.
time to which a clock value of zero corresponds. January 1, 1900, 0
A.M. Greenwich Mean Time is recommended as the standard epoch for the
clock, although some early support of the TOD clock is not based on this
epoch.
--
virtualization experience starting Jan1968, online at home since Mar1970
Lawrence D'Oliveiro
2024-10-30 20:51:26 UTC
Permalink
the 370 hardware tod clock was spec'ed GMT since the start of the
century.
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.
Lynn Wheeler
2024-10-30 23:13:24 UTC
Permalink
Post by Lawrence D'Oliveiro
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.
some kernel software only had local time as displacement from GMT ...
and had to be reassembled and rebooted each time that displacement
change.
--
virtualization experience starting Jan1968, online at home since Mar1970
John Levine
2024-10-30 21:30:05 UTC
Permalink
Post by Lawrence D'Oliveiro
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?
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

I would be surprised if there were earlier systems that used UTC. If you don't
have remote access, you might as well use local time.

CTSS had a get time of day call which returned the date as MMDDYY BCD, and the
time in either 60ths of a second or BCD HHMM.M. No mention of time zones so I
would assume it was local time in Boston.
--
Regards,
John Levine, ***@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly
Lawrence D'Oliveiro
2024-10-31 02:14:46 UTC
Permalink
Post by John Levine
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
Ah, you mean page 2-88.5? Confused me for a moment.

The declaration on that page looks like

declare clock_ entry returns (fixed bin(71));

71 bits ... pretty ambitious, even for a large system, in those days.
Of course 1901 was chosen to neatly avoid having to deal with 1900 not
being a leap year ...

I tried (Python)

math.log(time.time_ns() // 1000 + 2177452800 * 1_000_000) / math.log(2)

and that is about 52 bits today. So still a fair bit of headroom in a
64-bit int.
Peter Flass
2024-11-03 19:49:40 UTC
Permalink
Post by Lawrence D'Oliveiro
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?
Great question. I always thought clocks were set as such because it was
the standard before computers. Anytime I saw a TV broadcast of an
upcoming show, they'd say the time of broadcast plus or minus
GMT/UTC.
Daniel
Where are you. In the US they always give the times in Eastern and Pacific,
and the rest of us have to guess. OS/360 was pre-internet, so the operator
set the clock at IPL, to whatever they wanted, local or UTC.
--
Pete
Loading...