Sleep for 1000 years

Question

Some sleep commands implement a delay of an integer number of seconds. However, 2³² seconds is only about 100 years. Bug! What if you need a larger delay?

Make a program or a function which waits for 1000 years, with an error of less than ±10%. Because it's too time-consuming to test, please explain how/why your solution works! (unless it's somehow obvious)

You don't need to worry about wasting CPU power - it can be a busy-loop. Assume that nothing special happens while your program waits - no hardware errors or power failures, and the computer's clock magically continues running (even when it's on battery power).

What the solution should do after the sleep is finished:

• If it's a function: return to caller
• If it's a program: terminate (with or without error) or do something observable by user (e.g. display a message or play a sound)

Answer 1

C (gcc), 40 36 32 29 26 24 bytes

i;f(){--i&&f(sleep(7));}

Try it online!

Assumes that int is 32 bits on the target platform.

---

-3 thanks to @gastropner.

-1 recursive approach thanks to @AZTECCO.

4294967295*7/86400/365.25 ~ 952.69

Answer 2

Python 3 (Excluding CPython on Windows), 28 bytes

import time
time.sleep(3e10)

Try it online! (Remember to put something in your will so future generations can check that it ended on time.)

time.sleep(seconds) takes either an int or a float.

1000*365.2422*24*60*60/3e10 == 1.051897536 which is an error of less than 10%.

Answer 3

bash, 26 24 bytes

I think part of the challenge here is to not have a signed 32 bit overflow, so:

ping -i86400 -c365243 t.co

The idea here is to make 1000 years of pings (365243), once per day (86400).

"t.co" is simply a four character internet hostname (in this case, a link shortener). If your local host table has a one character hostname, you can subtract 3 bytes.

Edit: corvus-192 points out that country code ai resolves as a host, so you can write:

ping -i86400 -c365243 ai

As this will should work for anyone, I will accept this. Saved 2 bytes.

Answer 4

MATL, 6 5 bytes

35WY.

This waits for 34359738368 seconds, which is a little more than 1089 years and a half.

Don't try it online!

Explanation

35     % Push 35
W      % 2 raised to that. Gives 34359738368
Y.     % Pause for that many seconds

Answer 5

Ruby, 10 bytes

sleep 3e10

Try it online!

There are approximately \$3*10^{10}\$ seconds in a thousand years.

Answer 6

6502 Machine Code on an Apple II, 10 9 bytes

Code is actually platform-independent, other than it relies on the Apple's clock speed of 1.023 MHz for timing.

Code starts at address 0x0000:

0000: A2 CA F6 44 F0 FB D0 F8 F7

Saved an additional byte. Details are below original answer.

Original answer:

Code starts at address 0x0059:

0059: A2 08 F6 60 D0 FA CA D0 F9 F5

Disassembly:

loop1: 0059- A2 nn     LDX #$nn   ; 2 cyc
loop2: 005B- F6 60     INC $60,X  ; 6 cyc
       005D- D0 FA     BNE loop1  ; 2-3 cyc
       005F- CA        DEX        ; 2 cyc
       0060- D0 F9     BNE loop2  ; 2-3 cyc
       0062- pp        DB  $pp    ; data byte

This is a fairly simple routine that increments a multi-byte counter. When the counter rolls over, the last branch instruction gets modified so that it points to an RTS instruction, which provides the exit for the routine.

loop1 is taken for each increment of the counter and takes 11 cycles per iteration. loop2 is taken for each byte carried over and takes 13 cycles per iteration. So if we increment the counter N times, we spend approximately:

11*N + 13*(1/256 + 1/(256^2) + 1/(256^3) + ...)*N = 11.05*N cycles

1000 years is 365242*86400*1023000 = 32282717702400000 cycles

So we need N = 2921512914244345 +/- 10%

Or a range of 2629361622819911 - 3213664205668779
= 0x095763F583A447 - 0x0B6ACF816801AB

In the code above, set pp = 0xF5 and nn = 0x08.

This gives us a 7-byte counter in memory locations 0x62-0x68 (with MSB at lowest address, i.e. big endian). Only location 0x62 is initialized, so our starting counter value could be anywhere from 0xF5000000000000 to 0xF5FFFFFFFFFFFF.

We'll increment the counter until it rolls over to 0, which will cause the byte at 0x61 to increment by 1, which happens to be the branch target for loop2. On the first byte carry after rollover-- when the counter hits 0x100-- we'll hit the modified branch instruction for the first time. This will take us to address 0x5C (loop2+1). The 0x60 byte there is the opcode for "Return from Subroutine" (RTS) which provides our exit.

So our total loop count is between, 0x0A000000000101 and 0x0B000000000100, which is a subset of the range we calculated which gives us the necessary number of cycles +/- 10%.

Now that we have the exact starting and ending counter values, we could go back and calculate the exact cycle counts, but given how much margin there is, I'm willing to hand-wave that part.

You can actually test it out with smaller values of nn. For example nn of 4 will pause for several seconds.

9-byte answer:

0000- A2 CA     LDX #$CA   ; 2 cyc
0002- F6 44     INC $44,X  ; 6 cyc
0004- F0 FB     BEQ $0001  ; 2-3 cyc (rollover)
0006- D0 F8     BNE $0000  ; 2-3 cyc (non-rollover)
0008- F7        DB  $F7    ; data byte

Saved one byte by folding the DEX opcode into the argument for LDX.

Instead of 11.05 cycles, each counter increment is now 13 + 11*(1/256 + 1/(256^2) + ...) = 13.043 cycles.

Now we need 2475073064976549 +/- 10% iterations, or a range of 0x7E9F591BF7A2E - 0x9AC2C23EA071C.

So now we initialize the 7-byte counter to something between 0xF7000000000000 and 0xF7FFFFFFFFFFFF. This ends up giving between 0x08000000000001 and 0x09000000000000 loop iterations, which is within the +/-10% needed.

When the counter rolls over to 0, the last branch gets modified to jump to $0001, which leads to an increment of the BNE opcode itself (to a CMP instruction, which for our purpose is effectively a no-op). Code then falls through to $0008, which now contains a 0 (because of counter rollover). A 0 byte is a BRK instruction, which drops you back to the system monitor, ending the routine.

Answer 7

PowerShell, 35 32 24 21 19 bytes

1..3e4|%{sleep 1mb}

Try it online!

Strangely, the maximum seconds value for Start-Sleep is 2147483. No, I don't know why it's such an odd value. That works out to a little over 2 megabytes (2097152). 1mb * 30000 / 86400 / 365.25 is 996.821051030497, so a little under 1000 years. I could get more exact using a different value than 3e4, but this is within the allowed margin and I'm lazy.

Saved 3 bytes thanks to ceilingcat.
Saved 8 bytes thanks to Jeff Zeitlin.
Saved 3 bytes thanks to Neil.
Saved 2 bytes thanks to Mark Henderson and Nahuel Fouilleul.

Answer 8

05AB1E, 6 bytes

27;°.W

Inspired by the other answer in 05AB1E.

Waits for 10^27/2 milliseconds, or about 1002 years.

Explanation:

27            push the number 27
  ;           divide by 2
   °          replace X by 10 to the power of X
    .W        wait that number of milliseconds

Try it online!

Answer 9

Jelly, 8 bytes

32œS$ȷ9¡

Try it online!

A niladic link which waits for 32 seconds 1 billion times. 32,000,000,000 is within 10% of 31,557,600,000 seconds which is 1,000 years (ignoring leap seconds and ignoring the fact that centuries indivisible by 400 are not leap years).

Answer 10

Charcoal, 7 bytes

Ｆ³³ＲＸφ⁴

Try it online! Link is to verbose version of code with a speed up factor of 1e9 (obtained by changing the ⁴ into a a ¹) so that it doesn't time on TIO. Explanation:

Ｆ³³

Repeat 33 times.

ＲＸφ⁴

Refresh the screen, but delay 1000⁴ milliseconds between refreshes.

Although there are 33 refreshes, there are only 32 intervals, so the total delay is 32000000000000 milliseconds or approximately 1015 years.

Answer 11

Java (JDK), 23 bytes

v->Thread.sleep(7L<<42)

Try it online!

It's hard to find a short way to write a number in Java. Thread.sleep only accepts a long number of milliseconds. So the standard answer 3e10 doesn't work because it's a double. Casting it to a long would be the appropriate action. But it would still be 1000 too small. So enter 3e13 which is closer. But fortunately, 7L<<42 is 30,786,325,577,728, which is close to the actual count of 1000 years, and is a long without cast, so 4 bytes shorter than (long)3e13.

Credits

• -4 bytes thanks to Neil by replacing (long)3e13 with 7L<<42.

Answer 12

Batch, 41 25 bytes

^{-8 bytes thanks to AdmBorkBork
-6 bytes thanks to ceilingcat
-2 bytes thanks to inspiration from Neil}

ping 1 -n 31556952000>nul

Using 31,556,952 seconds / year and a (default) 1 second delay between each ping, this will wait 1000 years before returning nothing.

Note that ping 1 results in failure but it'll fail 31 billion times so that still works.

Answer 13

APL (Dyalog Unicode), 9 8 bytes^SBCS

-1 thanks to Eric Towers.

Full program. This works by observing that $$\sum_{n=1}^{8^6}n=3.44×10^{10}\approx3.16×10^{10}$$which is the number of seconds in a thousand years.

⎕dl¨⍳8*6

Don't try it online!

8*6 \$8^6=262144\$

⍳ ɩntegers until that

⎕dl¨ delay each of those many seconds

Answer 14

Wolfram Language (Mathematica), 11 bytes

Pause[2^35]

2 to the 35th power is about 8.9% greater than 31,556,926,000.

Answer 15

T-SQL, 56 bytes

DECLARE @ INT=0a:WAITFOR TIME'9:0'SET @+=1IF @<4E5GOTO a

• The SQL WAITFOR command is limited to 24 hours, so it has to go in a loop.
• WAITFOR has two options: DELAY that waits a certain length of time, or TIME which waits until a certain time of day. Turns out WAITFOR TIME'9:0' (which will pause until 9am the following day) is a couple of bytes shorter than WAITFOR DELAY'24:0'.
• Using a GOTO loop is shorter than a WHILE loop.
• I'm looping 4E5 times (400,000), which is within 10% of the 10-year (365,242 day) goal.
• If I start it today, this would complete in February, 3115

Answer 16

gbz80 machine code program, 40 (6 + 34) bytes

VBlank handler (put at 0x40)

CD 5A 01 F1 FB 76

Program after entrypoint (put at 0x150)

01 B7 02 21 FF FF 36 01 FB 76 2D 20 14 25 20 11
1D 20 0E 15 20 0B 0D 20 08 05 20 05 2F E0 21 E0
23 C9

Runs a timer that decrements every frame. At the Game Boy's frame rate, one thousand years is ~1,884,804,967,414 (0x1B6D7216BF6) frames (with a frame rate of 59.727500569606 fps and the assumption of 24 hours per day and 365.24 days per year). This program's timer runs for 0x1B6****FEFE frames. The stars are that the middle registers aren't initialized, and the bottom registers are used for an optimization, but the three most significant hex figures are correct and therefore the timer will be well within tolerance.

After the thousand years, the noise channel plays for a short while, and there will be a looping timer that will play the sound every ~149,339 years. Those are some good AAs.

Maybe it could be shorter if you want to cycle count instead of VBlank count.

Source:

section "VBlankInterrupt", ROM0[$40]
    call VBlankHandled
    pop af                  ; get rid of pushed return address
    ei                      ; enable interrupts
    db $76                  ; directly encoded halt, one byte saved over "halt"
                            ; ei and halt interact buggily, but it doesn't matter here because we discard the return address.

section "Header", ROM0[$100]
    jr AfterEntryPoint      ; thing for every Game Boy program, shouldn't count

    ds $150 - @, 0          ; Make room for the header

AfterEntryPoint:
    ld bc, $02B7            ; we have to set b one higher, because we decrement then check for zero. also did c because no reason not to and more accuracy
                            ; d and e will be set to their startup values.
    ld hl, $FFFF            ; double-use: part of timer and as a pointer
    ld [hl], $01            ; enable v-blank interrupt only
    ei
    db $76                  ; necessary halt to prevent stack underflow from return, again the return address is discarded so ei halt bug isn't a worry
VBlankHandled:
    dec l
    jr nz, .backToSleep
    dec h
    jr nz, .backToSleep
    dec e
    jr nz, .backToSleep
    dec d
    jr nz, .backToSleep
    dec c
    jr nz, .backToSleep
    dec b
    jr nz, .backToSleep
.madeItOut:
    cpl                     ; invert a, which is 01 from the pop
    ldh [$21], a
    ldh [$23], a            ; this and previous turn on and up the noise channel, which briefly plays because of time limit not being turned off
.backToSleep:
    ret

Answer 17

R, 24 bytes

sapply(1:25e4,Sys.sleep)

Try it online!

A solid starter, feels like there's optimisation to be had with a different function & number combo. This sleeps for 1s, then 2s, then 3s, then 4s... up to 250000s, at which point it's been running for about 990 years and outputs a list of 250k empty elements.

Answer 18

Lua, 38 bytes

t=os.time;o=t()+2^35while t()<o do end

Try it online!

Being ANSI C compliant, Lua does not implement any sleep functions, so we have to make one ourselves. Oh, and make sure to keep the dust off that One Thousand Year Computer, we're busy waiting.

Lua, 38 bytes

t=os.time;o=t()+2^35repeat until o<t()

Try it online!

Same thing, different loop. Tried to see if I can save some bytes, but nope.

Answer 19

C# (Visual C# Interactive Compiler), 59 bytes

b=>{for(var d=DateTime.Now.AddYears(999);d>DateTime.Now;);}

Can be tested by replacing AddYears() with AddSeconds()

Try it online!

Answer 20

Mumps (M): 7 Bytes

H 9**11

Mumps likes single-letter commands & big numbers... H(ang) sleeps for ## of seconds; 9 to the 11th power gives 31381059609 seconds, which is almost 0.6% low for 1000 years; well within the margin of error.

Keeping with the 7 byte code length, I tested "power of 9" sleep times on 2 different Mumps implementations; the largest power of 9 on YottaDB/GT.M I can find without numeric overflow would be:

H 9**49

which gives a sleep time of just over 1,814 decillion millennia. InterSystems' Cache doesn't overflow and can go to:

H 9**99

which gives 9.352x10⁸³ millennia. That's quite a nap in 7 bytes!

Answer 21

Pyth, 10 bytes

VT.dC"¼€

Try it online!

There are exactly 31,557,600 seconds in the Julian astronomical year., totalling 31,557,600,000 seconds in 1000 years. 2^32 is about a tenth of this, so we just wait for 3,155,760,000 seconds ten times. Note that € is a blank codepoint in the TIO, not sure why it translates to this on SE

Here you can see that C"¼€ is equal to 3,155,760,000

And here is an example that waits for only 22 seconds using a similar method

Pyth, 8 bytes

.dC"XúÃ

Try it online!

Alternatively, this one just uses C"XúÃ for 31,557,600,000. I thought it was more in line with the spirit of the challenge to have a 2^32 limit, though

---

The average length of a sidereal year, however, is 365.256363004 days or around 31,558,149.763 seconds, giving us a total of ~31,558,149,764 seconds in 1000 years. In this case, the more accurate solution would be

This: VT.dC"¼ê@

This:.dC"Y&ƒ(1 byte longer than Julian solution)

Answer 22

Perl 5, 18 bytes

sleep 1e9for 1..30

Try it online!

10 bytes (doesn't work)

sleep 3e10

Try it online!

Answer 23

PHP, 30 bytes

The time() function can be used instead of microtime(1), as when plused with 3e10, PHP converts the value into a float, even when the original value is an int and thereby save some more bytes.

time_sleep_until(time()+3e10);

See how php converts values


As stated by "manassehkatz-Reinstate Monica" a flag can be set to make it run without the tags in PHP, so a more clean version is here made. (36 bytes)

time_sleep_until(microtime(1)+3e10);

Google tells me that 1000 years = 3.1556926 × 10¹⁰ seconds (31,556,926,000)
The method cloud even be made recoverable in the event of power failures. (not done in this example)

<?php time_sleep_until(microtime(true)+31556926000)); ?>

The shorter but more imprecise version (45 bytes with the php tags)

<?php time_sleep_until(microtime(1)+3e10); ?>

With a correction from "Kaddath" this option below is dropped as the documentation state that it is a int not a float used in sleep()
It can be done like so:

<?php sleep(31556926000); ?>

Try it online!

Answer 24

C# (Visual C# Interactive Compiler), 38 37 bytes

this waits 1 + 2 + 3.. +77e5-1 + 77e5ms.

I got this 77e5 magic number using the formula (x+1)/2*x=3e13 where x results in approximately 7.745.967 which I shortened to 77e5.

To check if it still falls in the allowed range I did 1000*365.25*24*3600*1000/((77e5+1)/2*77e5) which is 1.064 aka 6.45% of target

update : 8e6 results in 0.98 more precise and less bytes.

for(var i=0;i++<8e6;)Thread.Sleep(i);

Try it online!

Answer 25

05AB1E, 5 bytes

₆9e.W

Sleeps for about 1082 years.

Try it online!

₆         # push 36
 9        # push 9
  e       # nPr (number of 9-element permutations of a 36-element list)
   .W     # wait that many milliseconds

Answer 26

SmileBASIC, 19 bytes

@L
WAIT 12e7GOSUB@L

Waits 120 000 000 frames (around 21.2 days), and loops until the GOSUB stack overflows (after 16383 iterations)
This lasts 1038.32 years

Answer 27

JavaScript (Node.js), 70, 67, 34 bytes

-3 thanks to Joost K, see their answer for why I used 8e6
-33 thanks to Benjamin Gruenbaum for pointing out callbacks are better, using the concept of his answer

I've found 2 ways of solving this problem. The first defines a globally:

(f=_=>a&&setTimeout(f,--a))(a=8e6)

the other method passes a through each time, using setTimeout's further args:

(f=a=>a&&setTimeout(f,--a,a))(8e6)

These solutions remain the same length when using IIFEs or just calling the function manually.

Answer 28

TI-BASIC, 17 bytes

For(I,0,2^32:rand(564:End

TI-BASIC doesn't have any wait commands/functions, so I just used one of the slowest functions available: generating random lists!

Generating a random list of 564 elements takes \$\approx7.95\$ seconds to make and the loop goes through \$2^{32}\$ iterations, so that results in \$7.95*2^{32}=34144990003.2\$ seconds or \$1082.01255\$ years.

Answer 29

Matlab, 12 bytes

pause(3e+10)

This will sleep for 951 years which is within 10% of 1000 years. Note that Matlab can sleep for a floating number of seconds.

This is my first ever answer on CodeGolf :)

Answer 30

x86-64 function, 10 bytes

6A 16 59 48 C1 E1 1F E0 FE C3

In assembly:

sleep_for_a_thousand_years:
    push 0x17
    pop rcx
    shl rcx,52
    loopnz $
    ret

This is a function

The loopnz opcode decrements the rcx register and jumps if the zero flag is not set and rcx!=0 after it is decremented. $ denotes the address of the loopnz address itself, so this just loops back to the same instruction over and over until rcx is zero.

loopnz is infamously slow, and the code before sets rcx to 103,582,791,429,521,408. So this will loop 103,582,791,429,521,408 times, which should take 1012 years, based on some benchmarks I did on TIO. (The number may need to be tweaked a bit if you have some overclocked monstrosity though.)

Try it online! ... Actually, maybe skip that just this once.