Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #100032 > unrolled thread

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

Back to article view | Back to comp.lang.c

Contents

  'Leap Second' to Be Added on New Year's Eve This Year "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2016-12-22 21:43 +0800
    Re: 'Leap Second' to Be Added on New Year's Eve This Year Siri Cruise <chine.bleu@yahoo.com> - 2016-12-22 05:48 -0800
      Re: 'Leap Second' to Be Added on New Year's Eve This Year "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2016-12-22 22:09 +0800
      Re: 'Leap Second' to Be Added on New Year's Eve This Year Krzysztof Mitko <invalid@kmitko.at.list.dot.pl> - 2016-12-24 13:47 +0100
        Re: 'Leap Second' to Be Added on New Year's Eve This Year Siri Cruise <chine.bleu@yahoo.com> - 2016-12-24 05:39 -0800
    Re: 'Leap Second' to Be Added on New Year's Eve This Year Mark Lloyd <not@mail.invalid> - 2016-12-22 14:31 -0600
      Re: 'Leap Second' to Be Added on New Year's Eve This Year Mark Storkamp <mstorkamp@yahoo.com> - 2016-12-23 08:34 -0600
        Re: 'Leap Second' to Be Added on New Year's Eve This Year "J-P. Rosen" <rosen@adalog.fr> - 2016-12-23 16:55 +0100
        Re: 'Leap Second' to Be Added on New Year's Eve This Year Ken Brody <kenbrody@spamcop.net> - 2016-12-30 11:17 -0500
          Re: 'Leap Second' to Be Added on New Year's Eve This Year Gene Wirchenko <genew@telus.net> - 2016-12-30 09:38 -0800
            Re: 'Leap Second' to Be Added on New Year's Eve This Year hah <hah@no.email.stupid.invalid> - 2016-12-30 15:59 -0600
          Re: 'Leap Second' to Be Added on New Year's Eve This Year Mark Lloyd <not@mail.invalid> - 2016-12-30 15:47 -0600
          Re: 'Leap Second' to Be Added on New Year's Eve This Year Ken Blake <Ken@invalid.news.com> - 2016-12-30 15:14 -0700
            Re: 'Leap Second' to Be Added on New Year's Eve This Year Kaz Kylheku <221-501-9011@kylheku.com> - 2016-12-30 23:26 +0000
      Re: 'Leap Second' to Be Added on New Year's Eve This Year "James R. Kuyper" <jameskuyper@verizon.net> - 2017-01-03 20:46 -0500
    Re: 'Leap Second' to Be Added on New Year's Eve This Year Jason <jason_warren@ieee.DELETE.org> - 2016-12-22 17:14 -0500
      Re: 'Leap Second' to Be Added on New Year's Eve This Year "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-12-22 14:38 -0800
      Re: 'Leap Second' to Be Added on New Year's Eve This Year "Jonathan N. Little" <lws4art@gmail.com> - 2016-12-22 17:40 -0500
        Re: 'Leap Second' to Be Added on New Year's Eve This Year Jason <jason_warren@ieee.org> - 2016-12-23 19:57 -0500
          Re: 'Leap Second' to Be Added on New Year's Eve This Year Char Jackson <none@none.invalid> - 2016-12-23 21:44 -0600
            Re: 'Leap Second' to Be Added on New Year's Eve This Year "James Wilkinson Sword" <imvalid@somewear.com> - 2016-12-31 23:42 +0000
      Re: 'Leap Second' to Be Added on New Year's Eve This Year Ken Brody <kenbrody@spamcop.net> - 2016-12-30 11:16 -0500
        Re: 'Leap Second' to Be Added on New Year's Eve This Year Mark Lloyd <not@mail.invalid> - 2016-12-30 15:58 -0600
          Re: 'Leap Second' to Be Added on New Year's Eve This Year Keith Thompson <kst-u@mib.org> - 2016-12-30 14:37 -0800
            Re: 'Leap Second' to Be Added on New Year's Eve This Year Mark Lloyd <not@mail.invalid> - 2016-12-30 19:16 -0600
              Re: 'Leap Second' to Be Added on New Year's Eve This Year Keith Thompson <kst-u@mib.org> - 2016-12-30 17:48 -0800
                Re: 'Leap Second' to Be Added on New Year's Eve This Year Jorgen Grahn <grahn+nntp@snipabacken.se> - 2016-12-31 10:08 +0000
                Re: 'Leap Second' to Be Added on New Year's Eve This Year Mark Lloyd <not@mail.invalid> - 2016-12-31 14:20 -0600
                Re: 'Leap Second' to Be Added on New Year's Eve This Year Mark Lloyd <not@mail.invalid> - 2016-12-31 14:34 -0600
                  Re: 'Leap Second' to Be Added on New Year's Eve This Year Wally W. <ww84wa@aim.com> - 2016-12-31 16:45 -0500
                    Re: 'Leap Second' to Be Added on New Year's Eve This Year Ken Blake <Ken@invalid.news.com> - 2016-12-31 16:34 -0700
                      Re: 'Leap Second' to Be Added on New Year's Eve This Year "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-12-31 17:15 -0800
                      Re: 'Leap Second' to Be Added on New Year's Eve This Year Wally W. <ww84wa@aim.com> - 2016-12-31 20:52 -0500
                      Re: 'Leap Second' to Be Added on New Year's Eve This Year Richard Heathfield <rjh@cpax.org.uk> - 2017-01-01 12:22 +0000
                      Re: 'Leap Second' to Be Added on New Year's Eve This Year Mark Lloyd <not@mail.invalid> - 2017-01-01 15:47 -0600
                  Re: 'Leap Second' to Be Added on New Year's Eve This Year Keith Thompson <kst-u@mib.org> - 2016-12-31 13:59 -0800
                Re: 'Leap Second' to Be Added on New Year's Eve This Year Wally W. <ww84wa@aim.com> - 2017-01-01 13:46 -0500
                  Re: 'Leap Second' to Be Added on New Year's Eve This Year Mark Lloyd <not@mail.invalid> - 2017-01-01 16:12 -0600
                    Re: 'Leap Second' to Be Added on New Year's Eve This Year Wally W. <ww84wa@aim.com> - 2017-01-01 19:44 -0500
                      Re: 'Leap Second' to Be Added on New Year's Eve This Year Wally W. <ww84wa@aim.com> - 2017-01-01 22:31 -0500
                    Re: 'Leap Second' to Be Added on New Year's Eve This Year Ken Blake <Ken@invalid.news.com> - 2017-01-02 11:23 -0700
                      Re: 'Leap Second' to Be Added on New Year's Eve This Year Mark Lloyd <not@mail.invalid> - 2017-01-02 19:03 -0600
                    Re: 'Leap Second' to Be Added on New Year's Eve This Year Mark Storkamp <mstorkamp@yahoo.com> - 2017-01-02 13:46 -0600
                      Re: 'Leap Second' to Be Added on New Year's Eve This Year Wolf K <wolfmac@sympatico.ca> - 2017-01-02 14:55 -0500
                        Re: 'Leap Second' to Be Added on New Year's Eve This Year Andy Burns <usenet@andyburns.uk> - 2017-01-02 20:00 +0000
                          Re: 'Leap Second' to Be Added on New Year's Eve This Year Sam E <why.should.this@be.email.invalid> - 2017-01-02 19:07 -0600
                            Re: 'Leap Second' to Be Added on New Year's Eve This Year Gareth Owen <gwowen@gmail.com> - 2017-01-03 06:45 +0000
                              Re: 'Leap Second' to Be Added on New Year's Eve This Year Wolf K <wolfmac@sympatico.ca> - 2017-01-03 09:42 -0500
                              Re: 'Leap Second' to Be Added on New Year's Eve This Year "Cybe R. Wizard" <cybe_r_wizard@WizardsTower.invalid> - 2017-01-03 11:27 -0600
                                Re: 'Leap Second' to Be Added on New Year's Eve This Year Caver1 <caver1@inthemud.org> - 2017-01-03 14:25 -0500
                              Re: 'Leap Second' to Be Added on New Year's Eve This Year "James R. Kuyper" <jameskuyper@verizon.net> - 2017-01-03 17:34 -0500
                        Re: 'Leap Second' to Be Added on New Year's Eve This Year Mark Storkamp <mstorkamp@yahoo.com> - 2017-01-02 14:20 -0600
                          Re: 'Leap Second' to Be Added on New Year's Eve This Year Wolf K <wolfmac@sympatico.ca> - 2017-01-02 15:36 -0500
                          Re: 'Leap Second' to Be Added on New Year's Eve This Year "James R. Kuyper" <jameskuyper@verizon.net> - 2017-01-04 12:09 -0500
                            Re: 'Leap Second' to Be Added on New Year's Eve This Year Wolf K <wolfmac@sympatico.ca> - 2017-01-04 19:12 -0500
                      Re: 'Leap Second' to Be Added on New Year's Eve This Year Wally W. <ww84wa@aim.com> - 2017-01-02 15:06 -0500
                        Re: 'Leap Second' to Be Added on New Year's Eve This Year Mark Lloyd <not@mail.invalid> - 2017-01-02 19:10 -0600
                          Re: 'Leap Second' to Be Added on New Year's Eve This Year Wally W. <ww84wa@aim.com> - 2017-01-02 22:56 -0500
                        Re: 'Leap Second' to Be Added on New Year's Eve This Year "James R. Kuyper" <jameskuyper@verizon.net> - 2017-01-04 12:34 -0500
                          Re: 'Leap Second' to Be Added on New Year's Eve This Year Mark Lloyd <not@mail.invalid> - 2017-01-04 15:32 -0600
                            Re: 'Leap Second' to Be Added on New Year's Eve This Year Keith Thompson <kst-u@mib.org> - 2017-01-04 13:51 -0800
                              Re: 'Leap Second' to Be Added on New Year's Eve This Year Real Troll <real.troll@trolls.com> - 2017-01-04 19:02 -0400
                              Re: 'Leap Second' to Be Added on New Year's Eve This Year Mark Lloyd <not@mail.invalid> - 2017-01-04 22:37 -0600
                            Re: 'Leap Second' to Be Added on New Year's Eve This Year "James R. Kuyper" <jameskuyper@verizon.net> - 2017-01-04 17:21 -0500
                              Re: 'Leap Second' to Be Added on New Year's Eve This Year "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-01-04 16:35 -0800
                                Re: 'Leap Second' to Be Added on New Year's Eve This Year asetofsymbols@gmail.com - 2017-01-06 01:53 -0800
                                  Re: 'Leap Second' to Be Added on New Year's Eve This Year asetofsymbols@gmail.com - 2017-01-06 01:58 -0800
                            Re: 'Leap Second' to Be Added on New Year's Eve This Year Gene Wirchenko <genew@telus.net> - 2017-01-05 09:20 -0800
                              Re: 'Leap Second' to Be Added on New Year's Eve This Year "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-01-05 10:23 -0800
                              [OT] Meaning and truth (Was Re: 'Leap Second' to Be Added on New Year's Eve This Year) Wolf K <wolfmac@sympatico.ca> - 2017-01-05 13:34 -0500
                            Re: 'Leap Second' to Be Added on New Year's Eve This Year Caver1 <caver1@inthemud.org> - 2017-01-07 17:20 -0500
                              Re: 'Leap Second' to Be Added on New Year's Eve This Year Kaz Kylheku <221-501-9011@kylheku.com> - 2017-01-07 22:57 +0000
                                Re: 'Leap Second' to Be Added on New Year's Eve This Year "James R. Kuyper" <jameskuyper@verizon.net> - 2017-01-07 19:06 -0500
                                  Re: 'Leap Second' to Be Added on New Year's Eve This Year Kaz Kylheku <221-501-9011@kylheku.com> - 2017-01-08 06:16 +0000
                                    Re: 'Leap Second' to Be Added on New Year's Eve This Year "James R. Kuyper" <jameskuyper@verizon.net> - 2017-01-08 11:19 -0500
                      Re: 'Leap Second' to Be Added on New Year's Eve This Year Mark Lloyd <not@mail.invalid> - 2017-01-02 19:05 -0600
                      Re: 'Leap Second' to Be Added on New Year's Eve This Year "James Wilkinson Sword" <imvalid@somewear.com> - 2017-01-04 00:28 +0000
              Re: 'Leap Second' to Be Added on New Year's Eve This Year raltbos@xs4all.nl (Richard Bos) - 2017-01-01 10:01 +0000
            Re: 'Leap Second' to Be Added on New Year's Eve This Year Mark Lloyd <not@mail.invalid> - 2016-12-31 14:29 -0600
    Re: 'Leap Second' to Be Added on New Year's Eve This Year "James Wilkinson Sword" <imvalid@somewear.com> - 2016-12-31 21:57 +0000
      Re: 'Leap Second' to Be Added on New Year's Eve This Year "James R. Kuyper" <jameskuyper@verizon.net> - 2017-01-03 20:06 -0500
        Re: 'Leap Second' to Be Added on New Year's Eve This Year "James Wilkinson Sword" <imvalid@somewear.com> - 2017-01-04 15:44 +0000
          Re: 'Leap Second' to Be Added on New Year's Eve This Year "James R. Kuyper" <jameskuyper@verizon.net> - 2017-01-04 14:11 -0500
            Re: 'Leap Second' to Be Added on New Year's Eve This Year "James Wilkinson Sword" <imvalid@somewear.com> - 2017-01-04 19:58 +0000
        Re: 'Leap Second' to Be Added on New Year's Eve This Year Richard Heathfield <rjh@cpax.org.uk> - 2017-01-04 16:17 +0000
          Re: 'Leap Second' to Be Added on New Year's Eve This Year "James Wilkinson Sword" <imvalid@somewear.com> - 2017-01-04 21:03 +0000
            Re: 'Leap Second' to Be Added on New Year's Eve This Year "Osmium" <r124c4u102@comcast.net> - 2017-01-05 14:15 -0600
              Re: 'Leap Second' to Be Added on New Year's Eve This Year "James Wilkinson Sword" <imvalid@somewear.com> - 2017-01-06 01:26 +0000
        Re: 'Leap Second' to Be Added on New Year's Eve This Year antispam@math.uni.wroc.pl - 2017-01-05 19:28 +0000
          Re: 'Leap Second' to Be Added on New Year's Eve This Year "James Wilkinson Sword" <imvalid@somewear.com> - 2017-01-05 21:41 +0000
    Re: 'Leap Second' to Be Added on New Year's Eve This Year Dänk 42Ø <dank@nugget.org> - 2017-01-02 07:08 +0000
      Re: 'Leap Second' to Be Added on New Year's Eve This Year Keith Thompson <kst-u@mib.org> - 2017-01-01 23:46 -0800
        Re: 'Leap Second' to Be Added on New Year's Eve This Year Dänk 42Ø <dank@nugget.org> - 2017-01-02 21:56 +0000
          Re: 'Leap Second' to Be Added on New Year's Eve This Year Keith Thompson <kst-u@mib.org> - 2017-01-02 15:38 -0800
      Re: 'Leap Second' to Be Added on New Year's Eve This Year "James R. Kuyper" <jameskuyper@verizon.net> - 2017-01-03 20:26 -0500

Page 2 of 5 — ← Prev page 1 [2] 3 4 5  Next page →

#100747

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

[toc] | [prev] | [next] | [standalone]

#100670

On 12/22/2016 5:14 PM, Jason wrote:
> In article <o3gl85$j26$1@dont-email.me>, toylet.toylet@gmail.com says...
>> A "leap second" will be added to the world's official clocks on Dec. 31
>> at 23 hours, 59 minutes and 59 seconds Coordinated Universal Time (UTC),
>>
>
> Google has an interesting approach to this to make sure that the 1-
> second adjustment doesn't cause problems. They "smear" the change over a
> longer period of time:
>
> https://googleblog.blogspot.com/2011/09/time-technology-and-leaping-seconds.html

C already handles this.

My <time.h> describes the "tm_sec" entry of "struct tm" with:

     int tm_sec;			/* Seconds.	[0-60] (1 leap second) */

-- 
Kenneth Brody

[toc] | [prev] | [next] | [standalone]

#100704

On 12/30/2016 10:16 AM, Ken Brody wrote:

[snip]

> C already handles this.
>
> My <time.h> describes the "tm_sec" entry of "struct tm" with:
>
>     int tm_sec;            /* Seconds.    [0-60] (1 leap second) */
>

I thought the time was actually stored in a single integer, then as 
appropriate, decoded into that structure.

Does that single integer have different values for 23:59:69 and for 
23:59:60? If not, how would tm_sec ever be 60?

The way I heard it is that that one second (23:59:59 GMT) would actually 
last 2 seconds (it would take 2 seconds for the clock to change, instead 
of the usual 1). If a program was requesting time() once a second, it 
would get the same value twice agt the end of the year.

BTW, the "end of the year" should come at 6PM here, since this is the 
Central time zone. I should be able to watch the clock on my webpage 
(updated by Javascript) show 5:59:59 for 2 seconds.

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

Losing your faith is a lot like losing your virginity you don't realise
how irritating it was 'til it's gone.

[toc] | [prev] | [next] | [standalone]

#100709

Mark Lloyd <not@mail.invalid> writes:
> On 12/30/2016 10:16 AM, Ken Brody wrote:
>
> [snip]
>
>> C already handles this.
>>
>> My <time.h> describes the "tm_sec" entry of "struct tm" with:
>>
>>     int tm_sec;            /* Seconds.    [0-60] (1 leap second) */
>>
>
> I thought the time was actually stored in a single integer, then as 
> appropriate, decoded into that structure.

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

> Does that single integer have different values for 23:59:69 and for 
> 23:59:60? If not, how would tm_sec ever be 60?

The standard doesn't require the <time.h> functions to handle leap
seconds.  In the presence of a leap second, 23:59:59 and 23:59:60 *may*
correspond to different time_t values.

> The way I heard it is that that one second (23:59:59 GMT) would actually 
> last 2 seconds (it would take 2 seconds for the clock to change, instead 
> of the usual 1). If a program was requesting time() once a second, it 
> would get the same value twice agt the end of the year.

It depends on the OS.  On some systems, there is no 23:59:60, but
the progression of values returned by time_t is stretched out over
some longer period surrounding 00:00:00.

> BTW, the "end of the year" should come at 6PM here, since this is the 
> Central time zone. I should be able to watch the clock on my webpage 
> (updated by Javascript) show 5:59:59 for 2 seconds.

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

-- 
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"

[toc] | [prev] | [next] | [standalone]

#100721

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

>> Does that single integer have different values for 23:59:69 and for
>> 23:59:60? If not, how would tm_sec ever be 60?
>
> The standard doesn't require the <time.h> functions to handle leap
> seconds.  In the presence of a leap second, 23:59:59 and 23:59:60 *may*
> correspond to different time_t values.
>
>> The way I heard it is that that one second (23:59:59 GMT) would actually
>> last 2 seconds (it would take 2 seconds for the clock to change, instead
>> of the usual 1). If a program was requesting time() once a second, it
>> would get the same value twice agt the end of the year.
>
> It depends on the OS.  On some systems, there is no 23:59:60, but
> the progression of values returned by time_t is stretched out over
> some longer period surrounding 00:00:00.
>

I think I'd still like to watch it to see what happens. My usual system 
is Firefox on Lubuntu.

>> BTW, the "end of the year" should come at 6PM here, since this is the
>> Central time zone. I should be able to watch the clock on my webpage
>> (updated by Javascript) show 5:59:59 for 2 seconds.
>
> That depends on how Javascript, or the code your web page is running,
> handles leap seconds.
>

It's using values returned by the methods in the Javascript DATE class.

For the digital clock, I don't think my code would have any problem 
displaying any 2-digit numeral returned by the method. The analog clock 
would probably show 11:59:60 the same way as 11:59:00, considering that 
0 and 60 would translate to the same angle.

Sorry if I made any mistakes there. It's harder typing around the cat in 
my lap (and trying to keep him from jumping on the keyboard).

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

Losing your faith is a lot like losing your virginity you don't realise
how irritating it was 'til it's gone.

[toc] | [prev] | [next] | [standalone]

#100722

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.

-- 
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"

[toc] | [prev] | [next] | [standalone]

#100729

["Followup-To:" header set to comp.lang.c.]
On Sat, 2016-12-31, 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.  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.

The problem with Y2K was also with software you didn't know existed,
or wasn't/couldn't be maintained. We'll still have that to worry about
in 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.

Hopefully, few file formats specify storing time_t in binary at all.
On Unix, anyway.

/Jorgen

-- 
  // Jorgen Grahn <grahn@  Oo  o.   .     .
\X/     snipabacken.se>   O  o   .

[toc] | [prev] | [next] | [standalone]

#100737

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]

[toc] | [prev] | [next] | [standalone]

#100740

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]

[toc] | [prev] | [next] | [standalone]

#100741

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.

[toc] | [prev] | [next] | [standalone]

#100746

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.

[toc] | [prev] | [next] | [standalone]

#100748

On Saturday, December 31, 2016 at 6:34:49 PM UTC-5, 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.

That's why it was so funny, Ken!  Didn't you get it?  I laughed so hard
I almost had my drink coming out of my nose.  My family looked at me and
I shared it with them.  Even my non-technical wife sat there with a big
smile shaking her head in subdued laughter.

Best regards,
Rick C. Hodgin

[toc] | [prev] | [next] | [standalone]

#100749

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.

[toc] | [prev] | [next] | [standalone]

#100768

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

[toc] | [prev] | [next] | [standalone]

#100818

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]

[toc] | [prev] | [next] | [standalone]

#100743

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"

[toc] | [prev] | [next] | [standalone]

#100800

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.

[toc] | [prev] | [next] | [standalone]

#100822

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]

[toc] | [prev] | [next] | [standalone]

#100839

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]

[toc] | [prev] | [next] | [standalone]

#100849

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]

[toc] | [prev] | [next] | [standalone]

Page 2 of 5 — ← Prev page 1 [2] 3 4 5  Next page →

Back to top | Article view | comp.lang.c

csiph-web