64-bit systems already use a 64-bit signed integer for time_t, which postpones the problem for about 292 billion years. And since C requires
long long to be at least 64 bits, I expect that 32-bit systems (and
smaller ones, if any) will transition to 64-bit time_t before 2038.
Unlike 2-digit years, I suspect that most stored time_t values (which
are rarely displayed) are in files that can be converted reasonably
easily.
That depends on how Javascript, or the code your web page is running,
handles leap seconds.
Mark Lloyd <not@mail.invalid> writes:
On 12/30/2016 04:37 PM, Keith Thompson wrote:[...]
[snip]
The time is stored in a time_t value returned by the time()
function. The time_t type is required to be a real type (integer
or floating-point, not complex) capable of representing times.
(On many systems it's a signed integer representing seconds since
1970-01-01 00:00:00 UTC.)
Used to be 32-bit, why I thought Y2K was going to be much less of a
problem than Y2.038K (Jan 17 2038 IIRC).
Tue 2038-01-19 03:14:08 UTC
64-bit systems already use a 64-bit signed integer for time_t, which postpones the problem for about 292 billion years. And since C requires
long long to be at least 64 bits, I expect that 32-bit systems (and
smaller ones, if any) will transition to 64-bit time_t before 2038.
Unlike 2-digit years, I suspect that most stored time_t values (which
are rarely displayed) are in files that can be converted reasonably
easily.
knew it was around that time, from having to deal with that when my
website was on a 32-bit server. IIRC the negative limit is in December 1901.
'Leap Second' to Be Added on New Year's Eve This Year.html>
Full story: <http://www.space.com/33361-leap-second-2016-atomic-clocks=
Revelers will get to celebrate New Year's Eve for a tiny bit longer1
than usual this year.
A "leap second" will be added to the world's official clocks on Dec. 3=
at 23 hours, 59 minutes and 59 seconds Coordinated Universal Time (UTC=),
which corresponds to 6:59:59 p.m. EST; the clocks will read 23:59:60m.
before ticking over to midnight. The goal is to keep two different
timescales in sync with each other.
The units of time had long been defined based on Earth's rotation
relative to distant celestial bodies. But that changed with the
invention of atomic clocks in the mid-20th century; scientists then
decided to base the second on the natural vibrations of the cesium ato=
[How to Build the Most Accurate Atomic Clocks (Video)]w
These two timescales don't match up exactly, however. Measurements sho=
that, because the moon's gravitational pull and other factors are
gradually slowing Earth's spin, the rotation-based scale loses between=
1.5 and 2 milliseconds per day compared to atomic time =E2=80=94 meani=ng the two
diverge by a full second every 500 to 750 days.
Leap seconds are a way to make up for this difference. Since 1972, the=
International Earth Rotation and Reference Systems Service (IERS) =E2=80==94 the
organization that keeps track of time for the world =E2=80=94 has adde=d 26 leap
seconds to atomic clocks, with the last such insertion coming on Juneer.
30, 2015.
The aim is to keep the two timescales within 0.9 seconds of each oth=
"We can easily change the time of an atomic clock, but it is notyly, it
possible to alter the Earth's rotational speed to match the atomic
clocks," officials with the U.S. Naval Observatory (USNO), which
maintains the Department of Defense's master clock, noted =E2=80=94 wr=
would seem =E2=80=94 in a statement today (July 6).
While Earth's rotation rate is slowing, the effect is quite subtle.
"Confusion sometimes arises over the misconception that the occasional=
insertion of leap seconds every few years indicates that the Earth
should stop rotating within a few millennia," USNO officials wrote.
"This is because some [people] mistake leap seconds to be a measure of=
the rate at which the Earth is slowing. The 1-second increments are,
however, indications of the accumulated difference in time between the=
two systems."c.
When leap seconds are added, they are always inserted on June 30 or De=
31 of a particular year. In 1972, IERS officials called for a leap
second to be inserted on both dates.
On 12/30/2016 07:48 PM, Keith Thompson wrote:[...]
Mark Lloyd <not@mail.invalid> writes:
Used to be 32-bit, why I thought Y2K was going to be much less of a[...]
problem than Y2.038K (Jan 17 2038 IIRC).
Tue 2038-01-19 03:14:08 UTC
I knew it was around that time, from having to deal with that when my website was on a 32-bit server. IIRC the negative limit is in December 1901.
On Sat, 31 Dec 2016 14:34:05 -0600, Mark Lloyd wrote:
knew it was around that time, from having to deal with that when my=20 >>website was on a 32-bit server. IIRC the negative limit is in December = 1901.
One of the problems when designing websites in 1901: there were no
browsers that supported UTF-8 encoding.
On Fri, 23 Dec 2016 19:57:25 -0500, Jason <jason_warren@ieee.org> wrote:
On Thu, 22 Dec 2016 17:40:35 -0500 "Jonathan N. Little"
<lws4art@gmail.com> wrote in article <o3hkmg$e6m$1@dont-email.me>
Neat idea. Although most services can handle a 1-second blip.
Google reported that there is some kind of lock required with multiple
servers that can't handle the sudden 1-second change. That's what
motivated them to adopt the smearing scheme.
For the networking gear that has an issue dealing with leap seconds,
it's not the leap second itself that causes problems. It's the *notice*
that a leap second is coming. Certain NTP clients totally choke when
they get that flag. It doesn't seem like it would be a big deal, but
it's a big deal, indeed. That's why leap smearing avoids the problem.
With smearing, there's no flag.
On Sat, 31 Dec 2016 16:45:39 -0500, Wally W. <ww84wa@aim.com> wrote:
On Sat, 31 Dec 2016 14:34:05 -0600, Mark Lloyd wrote:
knew it was around that time, from having to deal with that when my >>>website was on a 32-bit server. IIRC the negative limit is in December 1901. >>One of the problems when designing websites in 1901: there were no
browsers that supported UTF-8 encoding.
Actually, in 1901, there were no browsers at all.
On 12/30/2016 04:37 PM, Keith Thompson wrote:
The time is stored in a time_t value returned by the time()
function. The time_t type is required to be a real type (integer
or floating-point, not complex) capable of representing times.
(On many systems it's a signed integer representing seconds since 1970-01-01 00:00:00 UTC.)
Used to be 32-bit, why I thought Y2K was going to be much less of a
problem than Y2.038K (Jan 17 2038 IIRC).
On Sat, 31 Dec 2016 16:45:39 -0500, Wally W. <ww84wa@aim.com> wrote:
On Sat, 31 Dec 2016 14:34:05 -0600, Mark Lloyd wrote:
knew it was around that time, from having to deal with that when my
website was on a 32-bit server. IIRC the negative limit is in December 1901 .
One of the problems when designing websites in 1901: there were no
browsers that supported UTF-8 encoding.
Actually, in 1901, there were no browsers at all.
Mark Lloyd <not@mail.invalid> writes:
On 12/30/2016 04:37 PM, Keith Thompson wrote:[...]
[snip]
The time is stored in a time_t value returned by the time()
function. The time_t type is required to be a real type (integer
or floating-point, not complex) capable of representing times.
(On many systems it's a signed integer representing seconds since
1970-01-01 00:00:00 UTC.)
Used to be 32-bit, why I thought Y2K was going to be much less of a
problem than Y2.038K (Jan 17 2038 IIRC).
Tue 2038-01-19 03:14:08 UTC
64-bit systems already use a 64-bit signed integer for time_t, which >postpones the problem for about 292 billion years.
And since C requires
long long to be at least 64 bits, I expect that 32-bit systems (and
smaller ones, if any) will transition to 64-bit time_t before 2038.
Unlike 2-digit years, I suspect that most stored time_t values (which
are rarely displayed) are in files that can be converted reasonably
easily.
One of the problems when designing websites in 1901: there were no
browsers that supported UTF-8 encoding.
Actually, in 1901, there were no browsers at all.
As I understand it, NT time uses a signed integer and tops out at 0x7FFFFFFFFFFFFFFF = in the year 30828
Unhappily, no sources suggest using negative integers will allow
setting the timestamp before the year 1600.
Otherwise, timestamps could be set for any date in known history; as
in 4004 BC, which by some counts includes Day One.
On 01/01/2017 12:46 PM, Wally W. wrote:
[snip]
As I understand it, NT time uses a signed integer and tops out at
0x7FFFFFFFFFFFFFFF = in the year 30828
Unhappily, no sources suggest using negative integers will allow
setting the timestamp before the year 1600.
What is the resolution of this clock? You get hundreds of billions of
years if you count seconds since 1970.
1600 is a leap year, like 2000 and 2400. Maybe it has something to do
with that.
Otherwise, timestamps could be set for any date in known history; as
in 4004 BC, which by some counts includes Day One.
The PHP I use has a strange "hole", where you can't set (with mktime) a
year in the range of 0-100*. IIRC earlier years can be set, but it's one
off (it thinks there is a year 0). 4004 BC** would be specified as -4003.
* - I think this is a "convenience" that made sense with a 32-bit time_t >where it adds 2000 to 0-79 and 1900 to 80-100, both 0 and 100 become 2000.
** - I try to use CE / BCE instead of AD / BC. The numbers are the same,
and it avoids a particular assumption.
[snip]
On Sun, 1 Jan 2017 16:12:27 -0600, Mark Lloyd wrote:
On 01/01/2017 12:46 PM, Wally W. wrote:
[snip]
As I understand it, NT time uses a signed integer and tops out at
0x7FFFFFFFFFFFFFFF = in the year 30828
Unhappily, no sources suggest using negative integers will allow
setting the timestamp before the year 1600.
What is the resolution of this clock? You get hundreds of billions of >>years if you count seconds since 1970.
For Windows NT, GetSystemTimeAsFileTime is in 100s of nanonsconds
(tenths of microseconds) since 1/1/1600.
Doing the math:
0x7FFFFFFFFFFFFFFF = 9223372036854775807
So:
9223372036854775807 / 365.25 / 86400 / (1e7)
= 29,227
29,227 + 1600 = 30,827
That is close to 30,828.
My approximation for leap years is too crude for a span of 30,000+
years.
Unix tops out much later in the table at the link above.
If I want to use the same (really durable) hardware to retrieve my
backups in the year 292,000,000 AD, I should start using Linux now.
Actually, I would have liked to have started using Linux exclusively
years ago.
1600 is a leap year, like 2000 and 2400. Maybe it has something to do
with that.
Otherwise, timestamps could be set for any date in known history; as
in 4004 BC, which by some counts includes Day One.
The PHP I use has a strange "hole", where you can't set (with mktime) a >>year in the range of 0-100*. IIRC earlier years can be set, but it's one >>off (it thinks there is a year 0). 4004 BC** would be specified as -4003.
* - I think this is a "convenience" that made sense with a 32-bit time_t >>where it adds 2000 to 0-79 and 1900 to 80-100, both 0 and 100 become 2000.
** - I try to use CE / BCE instead of AD / BC. The numbers are the same, >>and it avoids a particular assumption.
[snip]
** - I try to use CE / BCE instead of AD / BC. The numbers are the same,==20
and it avoids a particular assumption.
** - I try to use CE / BCE instead of AD / BC. The numbers are the same,
and it avoids a particular assumption.
[snip]
In article <g9faA.342110$dF2.340169@fx44.iad>,
Mark Lloyd <not@mail.invalid> wrote:
** - I try to use CE / BCE instead of AD / BC. The numbers are the same,
and it avoids a particular assumption.
[snip]
And it's easy to remember too. Christian Era and Before Christian Era.
Paleontologists and such use YBP = Years Before Present.
In article <g9faA.342110$dF2.340169@fx44.iad>,
Mark Lloyd <not@mail.invalid> wrote:
** - I try to use CE / BCE instead of AD / BC. The numbers are the same,
and it avoids a particular assumption.
[snip]
And it's easy to remember too. Christian Era and Before Christian Era.
On 2017-01-02 14:46, Mark Storkamp wrote:
In article <g9faA.342110$dF2.340169@fx44.iad>,
Mark Lloyd <not@mail.invalid> wrote:
** - I try to use CE / BCE instead of AD / BC. The numbers are the same, >> and it avoids a particular assumption.
[snip]
And it's easy to remember too. Christian Era and Before Christian Era.
CE = Church of England BCE = Before Church of England. You'll need a calculator.
Heh heh.
Actually, it's "Common Era" and "Before Common Era". Paleontologists and such use YBP = Years Before Present.
In article <6fyaA.93321$%J2.54228@fx20.iad>,
Wolf K <wolfmac@sympatico.ca> wrote:
On 2017-01-02 14:46, Mark Storkamp wrote:
In article <g9faA.342110$dF2.340169@fx44.iad>,
Mark Lloyd <not@mail.invalid> wrote:
** - I try to use CE / BCE instead of AD / BC. The numbers are the same, >>>> and it avoids a particular assumption.
[snip]
And it's easy to remember too. Christian Era and Before Christian Era.
CE = Church of England BCE = Before Church of England. You'll need a
calculator.
Heh heh.
Actually, it's "Common Era" and "Before Common Era". Paleontologists and
such use YBP = Years Before Present.
What was it that happened 2018 years ago that made that year uncommon,
as opposed to the year 2017 years ago that was more in common with
todays year? I'd think anything before about AD 1900 is rather uncommon
by todays standards. In general, I think anything over 100 years old is always uncommon to the modern generation, so we should use a sliding
scale for years and it will always be 100 ME (modern era).
| Sysop: | digital man |
|---|---|
| Location: | Riverside County, California |
| Users: | 1,048 |
| Nodes: | 15 (0 / 15) |
| Uptime: | 40:31:02 |
| Calls: | 236,044 |
| Calls today: | 3 |
| Files: | 60,363 |
| D/L today: |
9,740 files (1,957M bytes) |
| Messages: | 289,464 |
| Posted today: | 2 |