• Re: 'Leap Second' to Be Added on New Year's Eve This Year

    From Not@mail.invalid@1:261/20 to All on Saturday, December 31, 2016 14:20:00
    Subject: Re: 'Leap Second' to Be Added on New Year's Eve This Year
    From: Mark Lloyd <not@mail.invalid>

    On 12/30/2016 07:48 PM, Keith Thompson wrote:

    [snip]

    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.

    Most will, I now expect few Y2.038K problems.

    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.


    I have some code on my website that stores times as decimal numerals.
    Until 2038, a 64-bit time_t stores exactly the same thing as a 32-bit
    time_t. There was no problem converting THAT to 64-bit. The only thing
    that changed was code to handle dates outside of the 32-bit range (which
    had been stored as julian dates).

    Since I want to see what my computer does with the leap second, so I
    have written this short PHP script (runs standalone, not as a webpage)
    that prints the GMT time every second until 10 seconds into the new year.

    ------------------------------------------------------------------------

    <?php

    for ($i = 0; $i < gmmktime(0,0,10,1,1,2017); $i++) {
    print gmdate('r') . "\n";
    usleep(999900);
    }




    --------------------------------------------------------------------------

    If you want to use it, you have less than 4 hours to get it going. It
    stops just after midnight so you can see the important part.

    --
    Mark Lloyd
    http://notstupid.us/

    "Call on God, but row away from the rocks." [Indian proverb]

    --- ViaMAIL!/WC v2.00
    * Origin: ViaMAIL! - Lightning Fast Mailer for Wildcat! (1:261/20)
  • From Not@mail.invalid@1:261/20 to All on Saturday, December 31, 2016 14:29:00
    Subject: Re: 'Leap Second' to Be Added on New Year's Eve This Year
    From: Mark Lloyd <not@mail.invalid>

    On 12/30/2016 04:37 PM, Keith Thompson wrote:

    [snip]

    That depends on how Javascript, or the code your web page is running,
    handles leap seconds.


    I did make a little change yesterday, to limit the Javascript Date.getSeconds() and Date.getUTCSeconds() function return value to 59,
    since the analog clock can't display properly (since it uses an angle 60
    = 0). That is, I have it show 23:59:60 as 23:59:59 rather than 23:59:00.

    --
    Mark Lloyd
    http://notstupid.us/

    "Call on God, but row away from the rocks." [Indian proverb]

    --- ViaMAIL!/WC v2.00
    * Origin: ViaMAIL! - Lightning Fast Mailer for Wildcat! (1:261/20)
  • From Not@mail.invalid@1:261/20 to All on Saturday, December 31, 2016 14:34:00
    Subject: Re: 'Leap Second' to Be Added on New Year's Eve This Year
    From: Mark Lloyd <not@mail.invalid>

    On 12/30/2016 07:48 PM, Keith Thompson wrote:
    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

    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.

    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.

    2^63 = 9.22337203685e+18 seconds, or 292,277,024,627 years (assuming
    leap year rules don't change).

    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.



    --
    Mark Lloyd
    http://notstupid.us/

    "Call on God, but row away from the rocks." [Indian proverb]

    --- ViaMAIL!/WC v2.00
    * Origin: ViaMAIL! - Lightning Fast Mailer for Wildcat! (1:261/20)
  • From Ww84wa@aim.com@1:261/20 to All on Saturday, December 31, 2016 15:45:00
    From: Wally W. <ww84wa@aim.com>
    Subject: Re: 'Leap Second' to Be Added on New Year's Eve This Year

    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.


    --- ViaMAIL!/WC v2.00
    * Origin: ViaMAIL! - Lightning Fast Mailer for Wildcat! (1:261/20)
  • From Imvalid@somewear.com@1:261/20 to All on Saturday, December 31, 2016 15:57:00
    From: "James Wilkinson Sword" <imvalid@somewear.com>
    Subject: Re: 'Leap Second' to Be Added on New Year's Eve This Year

    On Thu, 22 Dec 2016 13:43:58 -0000, Mr. Man-wai Chang <toylet.toylet@gma= il.com> wrote:

    'Leap Second' to Be Added on New Year's Eve This Year

    Full story: <http://www.space.com/33361-leap-second-2016-atomic-clocks=
    .html>

    Revelers will get to celebrate New Year's Eve for a tiny bit longer
    than usual this year.

    A "leap second" will be added to the world's official clocks on Dec. 3=
    1
    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:60
    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=
    m.
    [How to Build the Most Accurate Atomic Clocks (Video)]

    These two timescales don't match up exactly, however. Measurements sho=
    w
    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 June
    30, 2015.

    The aim is to keep the two timescales within 0.9 seconds of each oth=
    er.

    "We can easily change the time of an atomic clock, but it is not
    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=
    yly, it
    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."

    When leap seconds are added, they are always inserted on June 30 or De=
    c.
    31 of a particular year. In 1972, IERS officials called for a leap
    second to be inserted on both dates.

    I wish they'd turn their attentions to not turning the clocks back and f=
    orth all the fucking time!


    -- =

    I was doing some remolishments to my house the other day and accidentall=
    y defurbished it.

    --- ViaMAIL!/WC v2.00
    * Origin: ViaMAIL! - Lightning Fast Mailer for Wildcat! (1:261/20)
  • From Kst-u@mib.org@1:261/20 to All on Saturday, December 31, 2016 15:59:00
    From: Keith Thompson <kst-u@mib.org>
    Subject: Re: 'Leap Second' to Be Added on New Year's Eve This Year

    Mark Lloyd <not@mail.invalid> writes:
    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.

    Fri 1901-12-13 20:45:52 UTC

    If you have the GNU coreutils date command, you can do:

    $ date -u +'%a %Y-%m-%d %T %Z' -d @-2147483648
    Fri 1901-12-13 20:45:52 UTC
    $ date -u +'%a %Y-%m-%d %T %Z' -d @2147483647
    Tue 2038-01-19 03:14:07 UTC
    $

    --
    Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst> Working, but not speaking, for JetHead Development, Inc.
    "We must do something. This is something. Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

    --- ViaMAIL!/WC v2.00
    * Origin: ViaMAIL! - Lightning Fast Mailer for Wildcat! (1:261/20)
  • From Ken@invalid.news.com@1:261/20 to All on Saturday, December 31, 2016 17:34:00
    From: Ken Blake <Ken@invalid.news.com>
    Subject: Re: 'Leap Second' to Be Added on New Year's Eve This Year

    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=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.


    Actually, in 1901, there were no browsers at all.



    --- ViaMAIL!/WC v2.00
    * Origin: ViaMAIL! - Lightning Fast Mailer for Wildcat! (1:261/20)
  • From Imvalid@somewear.com@1:261/20 to All on Saturday, December 31, 2016 17:42:00
    From: "James Wilkinson Sword" <imvalid@somewear.com>
    Subject: Re: 'Leap Second' to Be Added on New Year's Eve This Year

    On Sat, 24 Dec 2016 03:44:36 -0000, Char Jackson <none@none.invalid> wrote:

    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.

    Can you explain exactly why they get upset?

    --
    A.I.D.S. = Arsehole Injected Death Sentence

    --- ViaMAIL!/WC v2.00
    * Origin: ViaMAIL! - Lightning Fast Mailer for Wildcat! (1:261/20)
  • From Ww84wa@aim.com@1:261/20 to All on Saturday, December 31, 2016 19:52:00
    From: Wally W. <ww84wa@aim.com>
    Subject: Re: 'Leap Second' to Be Added on New Year's Eve This Year

    On Sat, 31 Dec 2016 16:34:40 -0700, Ken Blake wrote:

    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.

    Also true.

    My statement remains accurate: In 1901, there were no browsers that
    supported UTF-8 encoding.

    It struck me funny that the negative limit for Unix time was mentioned
    on the heels of talk about a 32-bit server.

    One couldn't find 32-bit servers in 1901, either.

    I get it: Mark included the opposite extreme for completeness; and I
    did find it to be interesting.

    Still, the negative limit on Unix time doesn't hinder my efforts to
    back up disc files. All my files have time stamps later than 1901.


    --- ViaMAIL!/WC v2.00
    * Origin: ViaMAIL! - Lightning Fast Mailer for Wildcat! (1:261/20)
  • From Richard Bos@1:261/20 to All on Sunday, January 01, 2017 04:01:00
    From: raltbos@xs4all.nl (Richard Bos)
    Subject: Re: 'Leap Second' to Be Added on New Year's Eve This Year

    Mark Lloyd <not@mail.invalid> wrote:

    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).

    That's U*x, not C. Despite what some anarcho-politically motivated
    sources may tell you, they're not the same, and except for a very few
    months in their very beginnings, never have been.

    Richard

    --- ViaMAIL!/WC v2.00
    * Origin: ViaMAIL! - Lightning Fast Mailer for Wildcat! (1:261/20)
  • From Rjh@cpax.org.uk@1:261/20 to All on Sunday, January 01, 2017 06:22:00
    From: Richard Heathfield <rjh@cpax.org.uk>
    Subject: Re: 'Leap Second' to Be Added on New Year's Eve This Year

    On 31/12/16 23:34, Ken Blake wrote:
    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.

    *Whooooosh*

    --
    Richard Heathfield
    Email: rjh at cpax dot org dot uk
    "Usenet is a strange place" - dmr 29 July 1999
    Sig line 4 vacant - apply within

    --- ViaMAIL!/WC v2.00
    * Origin: ViaMAIL! - Lightning Fast Mailer for Wildcat! (1:261/20)
  • From Ww84wa@aim.com@1:261/20 to All on Sunday, January 01, 2017 12:46:00
    From: Wally W. <ww84wa@aim.com>
    Subject: Re: 'Leap Second' to Be Added on New Year's Eve This Year

    On Fri, 30 Dec 2016 17:48:04 -0800, Keith Thompson wrote:

    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.

    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.


    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.


    --- ViaMAIL!/WC v2.00
    * Origin: ViaMAIL! - Lightning Fast Mailer for Wildcat! (1:261/20)
  • From Not@mail.invalid@1:261/20 to All on Sunday, January 01, 2017 15:47:00
    Subject: Re: 'Leap Second' to Be Added on New Year's Eve This Year
    From: Mark Lloyd <not@mail.invalid>

    On 12/31/2016 05:34 PM, Ken Blake wrote:

    [snip]

    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.

    So, no browsers that support UTF-8.

    Also, no browsers that support HTML5 video playback.

    --
    Mark Lloyd
    http://notstupid.us/

    "In our sad condition, our only consolation is the expectancy of another
    life. Here below all is incomprehensible." [Martin Luther, Table Talk]

    --- ViaMAIL!/WC v2.00
    * Origin: ViaMAIL! - Lightning Fast Mailer for Wildcat! (1:261/20)
  • From Not@mail.invalid@1:261/20 to All on Sunday, January 01, 2017 16:12:00
    Subject: Re: 'Leap Second' to Be Added on New Year's Eve This Year
    From: Mark Lloyd <not@mail.invalid>

    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]

    --
    Mark Lloyd
    http://notstupid.us/

    "In our sad condition, our only consolation is the expectancy of another
    life. Here below all is incomprehensible." [Martin Luther, Table Talk]

    --- ViaMAIL!/WC v2.00
    * Origin: ViaMAIL! - Lightning Fast Mailer for Wildcat! (1:261/20)
  • From Ww84wa@aim.com@1:261/20 to All on Sunday, January 01, 2017 18:44:00
    From: Wally W. <ww84wa@aim.com>
    Subject: Re: 'Leap Second' to Be Added on New Year's Eve This Year

    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]


    --- ViaMAIL!/WC v2.00
    * Origin: ViaMAIL! - Lightning Fast Mailer for Wildcat! (1:261/20)
  • From Ww84wa@aim.com@1:261/20 to All on Sunday, January 01, 2017 21:31:00
    From: Wally W. <ww84wa@aim.com>
    Subject: Re: 'Leap Second' to Be Added on New Year's Eve This Year

    On Sun, 01 Jan 2017 19:44:48 -0500, Wally W. wrote:

    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.

    Above??!

    I meant this one:
    https://en.wikipedia.org/wiki/System_time

    I forgot to paste it before.


    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]


    --- ViaMAIL!/WC v2.00
    * Origin: ViaMAIL! - Lightning Fast Mailer for Wildcat! (1:261/20)
  • From Ken@invalid.news.com@1:261/20 to All on Monday, January 02, 2017 12:23:00
    From: Ken Blake <Ken@invalid.news.com>
    Subject: Re: 'Leap Second' to Be Added on New Year's Eve This Year

    On Sun, 1 Jan 2017 16:12:27 -0600, Mark Lloyd <not@mail.invalid>
    wrote:


    ** - I try to use CE / BCE instead of AD / BC. The numbers are the same,=
    =20
    and it avoids a particular assumption.


    And I try to use AD / BC instead of CE /BCE. CE and BCE don't avoid
    the assumption; as much as I would also like to avoid the assumption,
    since the numbers are the same, it still remains, just with different
    names.

    Giving something a different name doesn't really fix the problem, and
    I greatly dislike the pretense that it does.

    --- ViaMAIL!/WC v2.00
    * Origin: ViaMAIL! - Lightning Fast Mailer for Wildcat! (1:261/20)
  • From Mstorkamp@yahoo.com@1:261/20 to All on Monday, January 02, 2017 13:46:00
    From: Mark Storkamp <mstorkamp@yahoo.com>
    Subject: Re: 'Leap Second' to Be Added on New Year's Eve This Year

    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.

    --- ViaMAIL!/WC v2.00
    * Origin: ViaMAIL! - Lightning Fast Mailer for Wildcat! (1:261/20)
  • From Wolfmac@sympatico.ca@1:261/20 to All on Monday, January 02, 2017 13:55:00
    Subject: Re: 'Leap Second' to Be Added on New Year's Eve This Year
    From: Wolf K <wolfmac@sympatico.ca>

    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.

    --
    Best,
    Wolf K
    https://kirkwood40.blogspot.com
    It's called "opinion" because it's not knowledge.

    --- ViaMAIL!/WC v2.00
    * Origin: ViaMAIL! - Lightning Fast Mailer for Wildcat! (1:261/20)
  • From Usenet@andyburns.uk@1:261/20 to All on Monday, January 02, 2017 14:00:00
    From: Andy Burns <usenet@andyburns.uk>
    Subject: Re: 'Leap Second' to Be Added on New Year's Eve This Year

    Wolf K wrote:

    Paleontologists and such use YBP = Years Before Present.

    That's only so they can sell a re-print of their books every ten million
    or so years.

    --- ViaMAIL!/WC v2.00
    * Origin: ViaMAIL! - Lightning Fast Mailer for Wildcat! (1:261/20)
  • From Ww84wa@aim.com@1:261/20 to All on Monday, January 02, 2017 14:06:00
    From: Wally W. <ww84wa@aim.com>
    Subject: Re: 'Leap Second' to Be Added on New Year's Eve This Year

    On Mon, 02 Jan 2017 13:46:04 -0600, 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.

    Actually, the "C" in the politically correct, denialist version is
    "Common."

    If liberalism is so tolerant, what is the objection to centuries of
    use in millions of publications?

    http://www.todayifoundout.com/index.php/2015/11/difference-bce-ce-bc-ad-come/ BCE (Before Common Era) and BC (Before Christ) mean the same thing-
    previous to year 1 CE (Common Era). This is the same as the year AD 1
    (Anno Domini); the latter means "in the year of the lord," often
    translated as "in the year of our lord."

    What part of "mean the same thing" is lost on the politically correct revisionists?

    It is an irrational focus to work on obliterating reference to someone
    whom denialists claim died and rotted millennia ago.

    'What gets us into trouble is not what we don't know. It's what we
    know for sure that just ain't so.' -- Mark Twain

    Do the same denialist want to erase Mark Twain from history?



    --- ViaMAIL!/WC v2.00
    * Origin: ViaMAIL! - Lightning Fast Mailer for Wildcat! (1:261/20)
  • From Mstorkamp@yahoo.com@1:261/20 to All on Monday, January 02, 2017 14:20:00
    From: Mark Storkamp <mstorkamp@yahoo.com>
    Subject: Re: 'Leap Second' to Be Added on New Year's Eve This Year

    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).

    --- ViaMAIL!/WC v2.00
    * Origin: ViaMAIL! - Lightning Fast Mailer for Wildcat! (1:261/20)
  • From Wolfmac@sympatico.ca@1:261/20 to All on Monday, January 02, 2017 14:36:00
    Re: 'Leap Second' to Be Added on New Year's Eve This Year
    From: Wolf K <wolfmac@sympatico.ca>

    On 2017-01-02 15:20, Mark Storkamp wrote:
    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).

    Nicely argued pedantry. I like it. :-)

    You'll find 6 meanings for "common" in the Concise Oxford English
    Dictionary, and more in the big one.

    --
    Best,
    Wolf K
    https://kirkwood40.blogspot.com
    It's called "opinion" because it's not knowledge.

    --- ViaMAIL!/WC v2.00
    * Origin: ViaMAIL! - Lightning Fast Mailer for Wildcat! (1:261/20)