Return to Question

deleted 2 characters in body

edited Sep 12, 2022 at 15:01

I take a date at nanosecond precision:

$ start=$(date '+%s.%N')

...then print it:

$ echo ${start} 1662664850.030126174

So far so good. But look what I get when I printf with some arbitrarily huge precision:

1662664850.0301261739805340766906738281250000000000000000000000000

Q1. Did the date command actually populate the start variable with that much information, or are those digits just garbage?

Here's the second part of the question. Let's say I want to do some time math. Create an "end" timestamp:

$ end=$(date '+%s.%N') $ echo ${end} 1662665413.471669572 $ printf "%.55f\n" ${end} 1662665413.4716695720562711358070373535156250000000000000000000000

Now I get the result I expect using bc:

$ echo $(bc <<< ${end}-${start}) 563.441543398

But check out what I get when I use python or perl:

$ echo $(python -c "print(${end} - ${start})") 563.441543579 $ echo $(perl -e "print(${end} - ${start})") 563.441543579102

At a certain point, the number goes off the rails:
bc 563.441543398
python 563.441543579
perl 563.441543579102

 bc 563.441543398 python 563.441543579 perl 563.441543579102

Q2. The numbers are different, but not in a way that you'd expect if it was due to rounding. What gives?

System info:
Linux 3.10.0-1160.71.1.el7.x86_64 #1 SMP Wed Jun 15 08:55:08 UTC 2022

Command info:
date (GNU coreutils) 8.22
bc 1.06.95
Python 2.7.5
perl 5, version 16, subversion 3 (v5.16.3) built for x86_64-linux-thread-multi

I take a date at nanosecond precision:

$ start=$(date '+%s.%N')

...then print it:

$ echo ${start} 1662664850.030126174

So far so good. But look what I get when I printf with some arbitrarily huge precision:

1662664850.0301261739805340766906738281250000000000000000000000000

Q1. Did the date command actually populate the start variable with that much information, or are those digits just garbage?

Here's the second part of the question. Let's say I want to do some time math. Create an "end" timestamp:

$ end=$(date '+%s.%N') $ echo ${end} 1662665413.471669572 $ printf "%.55f\n" ${end} 1662665413.4716695720562711358070373535156250000000000000000000000

Now I get the result I expect using bc:

$ echo $(bc <<< ${end}-${start}) 563.441543398

But check out what I get when I use python or perl:

$ echo $(python -c "print(${end} - ${start})") 563.441543579 $ echo $(perl -e "print(${end} - ${start})") 563.441543579102

At a certain point, the number goes off the rails:
bc 563.441543398
python 563.441543579
perl 563.441543579102

Q2. The numbers are different, but not in a way that you'd expect if it was due to rounding. What gives?

System info:
Linux 3.10.0-1160.71.1.el7.x86_64 #1 SMP Wed Jun 15 08:55:08 UTC 2022

Command info:
date (GNU coreutils) 8.22
bc 1.06.95
Python 2.7.5
perl 5, version 16, subversion 3 (v5.16.3) built for x86_64-linux-thread-multi

I take a date at nanosecond precision:

$ start=$(date '+%s.%N')

...then print it:

$ echo ${start} 1662664850.030126174

So far so good. But look what I get when I printf with some arbitrarily huge precision:

1662664850.0301261739805340766906738281250000000000000000000000000

Q1. Did the date command actually populate the start variable with that much information, or are those digits just garbage?

Here's the second part of the question. Let's say I want to do some time math. Create an "end" timestamp:

$ end=$(date '+%s.%N') $ echo ${end} 1662665413.471669572 $ printf "%.55f\n" ${end} 1662665413.4716695720562711358070373535156250000000000000000000000

Now I get the result I expect using bc:

$ echo $(bc <<< ${end}-${start}) 563.441543398

But check out what I get when I use python or perl:

$ echo $(python -c "print(${end} - ${start})") 563.441543579 $ echo $(perl -e "print(${end} - ${start})") 563.441543579102

At a certain point, the number goes off the rails:

 bc 563.441543398 python 563.441543579 perl 563.441543579102

Q2. The numbers are different, but not in a way that you'd expect if it was due to rounding. What gives?

System info:
Linux 3.10.0-1160.71.1.el7.x86_64 #1 SMP Wed Jun 15 08:55:08 UTC 2022

Command info:
date (GNU coreutils) 8.22
bc 1.06.95
Python 2.7.5
perl 5, version 16, subversion 3 (v5.16.3) built for x86_64-linux-thread-multi

Aligning the given values.

Source Link

edit approved Sep 12, 2022 at 14:24

QuartzCristal

2.1k
5
25

I take a date at nanosecond precision:

$ start=$(date '+%s.%N')

...then print it:

$ echo ${start} 1662664850.030126174

So far so good. But look what I get when I printf with some arbitrarily huge precision:

1662664850.0301261739805340766906738281250000000000000000000000000

Q1. Did the date command actually populate the start variable with that much information, or are those digits just garbage?

Here's the second part of the question. Let's say I want to do some time math. Create an "end" timestamp:

$ end=$(date '+%s.%N') $ echo ${end} 1662665413.471669572 $ printf "%.55f\n" ${end} 1662665413.4716695720562711358070373535156250000000000000000000000

Now I get the result I expect using bc:

$ echo $(bc <<< ${end}-${start}) 563.441543398

But check out what I get when I use python or perl:

$ echo $(python -c "print(${end} - ${start})") 563.441543579 $ echo $(perl -e "print(${end} - ${start})") 563.441543579102

At a certain point, the number goes off the rails:
bc 563bc 563.441543398
python 563python 563.441543579
perl 563perl 563.441543579102

Q2. The numbers are different, but not in a way that you'd expect if it was due to rounding. What gives?

System info:
Linux 3.10.0-1160.71.1.el7.x86_64 #1 SMP Wed Jun 15 08:55:08 UTC 2022

Command info:
date (GNU coreutils) 8.22
bc 1.06.95
Python 2.7.5
perl 5, version 16, subversion 3 (v5.16.3) built for x86_64-linux-thread-multi

I take a date at nanosecond precision:

$ start=$(date '+%s.%N')

...then print it:

$ echo ${start} 1662664850.030126174

So far so good. But look what I get when I printf with some arbitrarily huge precision:

1662664850.0301261739805340766906738281250000000000000000000000000

Q1. Did the date command actually populate the start variable with that much information, or are those digits just garbage?

Here's the second part of the question. Let's say I want to do some time math. Create an "end" timestamp:

$ end=$(date '+%s.%N') $ echo ${end} 1662665413.471669572 $ printf "%.55f\n" ${end} 1662665413.4716695720562711358070373535156250000000000000000000000

Now I get the result I expect using bc:

$ echo $(bc <<< ${end}-${start}) 563.441543398

But check out what I get when I use python or perl:

$ echo $(python -c "print(${end} - ${start})") 563.441543579 $ echo $(perl -e "print(${end} - ${start})") 563.441543579102

At a certain point, the number goes off the rails:
bc 563.441543398
python 563.441543579
perl 563.441543579102

Q2. The numbers are different, but not in a way that you'd expect if it was due to rounding. What gives?

System info:
Linux 3.10.0-1160.71.1.el7.x86_64 #1 SMP Wed Jun 15 08:55:08 UTC 2022

Command info:
date (GNU coreutils) 8.22
bc 1.06.95
Python 2.7.5
perl 5, version 16, subversion 3 (v5.16.3) built for x86_64-linux-thread-multi

I take a date at nanosecond precision:

$ start=$(date '+%s.%N')

...then print it:

$ echo ${start} 1662664850.030126174

So far so good. But look what I get when I printf with some arbitrarily huge precision:

1662664850.0301261739805340766906738281250000000000000000000000000

Q1. Did the date command actually populate the start variable with that much information, or are those digits just garbage?

Here's the second part of the question. Let's say I want to do some time math. Create an "end" timestamp:

$ end=$(date '+%s.%N') $ echo ${end} 1662665413.471669572 $ printf "%.55f\n" ${end} 1662665413.4716695720562711358070373535156250000000000000000000000

Now I get the result I expect using bc:

$ echo $(bc <<< ${end}-${start}) 563.441543398

But check out what I get when I use python or perl:

$ echo $(python -c "print(${end} - ${start})") 563.441543579 $ echo $(perl -e "print(${end} - ${start})") 563.441543579102

At a certain point, the number goes off the rails:
bc 563.441543398
python 563.441543579
perl 563.441543579102

Q2. The numbers are different, but not in a way that you'd expect if it was due to rounding. What gives?

System info:
Linux 3.10.0-1160.71.1.el7.x86_64 #1 SMP Wed Jun 15 08:55:08 UTC 2022

Command info:
date (GNU coreutils) 8.22
bc 1.06.95
Python 2.7.5
perl 5, version 16, subversion 3 (v5.16.3) built for x86_64-linux-thread-multi

Became Hot Network Question

occurred Sep 9, 2022 at 6:31

Tables work in the preview, but don't work in the actual post. So I got rid of the table.

Source Link

edited Sep 8, 2022 at 20:25

The Poopsmith

I take a date at nanosecond precision:

$ start=$(date '+%s.%N')

...then print it:

$ echo ${start} 1662664850.030126174

So far so good. But look what I get when I printf with some arbitrarily huge precision:

1662664850.0301261739805340766906738281250000000000000000000000000

Q1. Did the date command actually populate the start variable with that much information, or are those digits just garbage?

Here's the second part of the question. Let's say I want to do some time math. Create an "end" timestamp:

$ end=$(date '+%s.%N') $ echo ${end} 1662665413.471669572 $ printf "%.55f\n" ${end} 1662665413.4716695720562711358070373535156250000000000000000000000

Now I get the result I expect using bc:

$ echo $(bc <<< ${end}-${start}) 563.441543398

But check out what I get when I use python or perl:

$ echo $(python -c "print(${end} - ${start})") 563.441543579 $ echo $(perl -e "print(${end} - ${start})") 563.441543579102

At a certain point, the number goes off the rails:
|Command|Output| |-------|------| |bc|563bc 563.441543398|
|python|563python 563.441543579|
|perl|563perl 563.441543579102|102

Q2. The numbers are different, but not in a way that you'd expect if it was due to rounding. What gives?

System info:
Linux 3.10.0-1160.71.1.el7.x86_64 #1 SMP Wed Jun 15 08:55:08 UTC 2022

Command info:
date (GNU coreutils) 8.22
bc 1.06.95
Python 2.7.5
perl 5, version 16, subversion 3 (v5.16.3) built for x86_64-linux-thread-multi

I take a date at nanosecond precision:

$ start=$(date '+%s.%N')

...then print it:

$ echo ${start} 1662664850.030126174

So far so good. But look what I get when I printf with some arbitrarily huge precision:

1662664850.0301261739805340766906738281250000000000000000000000000

Q1. Did the date command actually populate the start variable with that much information, or are those digits just garbage?

Here's the second part of the question. Let's say I want to do some time math. Create an "end" timestamp:

$ end=$(date '+%s.%N') $ echo ${end} 1662665413.471669572 $ printf "%.55f\n" ${end} 1662665413.4716695720562711358070373535156250000000000000000000000

Now I get the result I expect using bc:

$ echo $(bc <<< ${end}-${start}) 563.441543398

But check out what I get when I use python or perl:

$ echo $(python -c "print(${end} - ${start})") 563.441543579 $ echo $(perl -e "print(${end} - ${start})") 563.441543579102

At a certain point, the number goes off the rails:
|Command|Output| |-------|------| |bc|563.441543398| |python|563.441543579|
|perl|563.441543579102|

Q2. The numbers are different, but not in a way that you'd expect if it was due to rounding. What gives?

System info:
Linux 3.10.0-1160.71.1.el7.x86_64 #1 SMP Wed Jun 15 08:55:08 UTC 2022

Command info:
date (GNU coreutils) 8.22
bc 1.06.95
Python 2.7.5
perl 5, version 16, subversion 3 (v5.16.3) built for x86_64-linux-thread-multi

I take a date at nanosecond precision:

$ start=$(date '+%s.%N')

...then print it:

$ echo ${start} 1662664850.030126174

So far so good. But look what I get when I printf with some arbitrarily huge precision:

1662664850.0301261739805340766906738281250000000000000000000000000

Q1. Did the date command actually populate the start variable with that much information, or are those digits just garbage?

Here's the second part of the question. Let's say I want to do some time math. Create an "end" timestamp:

$ end=$(date '+%s.%N') $ echo ${end} 1662665413.471669572 $ printf "%.55f\n" ${end} 1662665413.4716695720562711358070373535156250000000000000000000000

Now I get the result I expect using bc:

$ echo $(bc <<< ${end}-${start}) 563.441543398

But check out what I get when I use python or perl:

$ echo $(python -c "print(${end} - ${start})") 563.441543579 $ echo $(perl -e "print(${end} - ${start})") 563.441543579102

At a certain point, the number goes off the rails:
bc 563.441543398
python 563.441543579
perl 563.441543579102

Q2. The numbers are different, but not in a way that you'd expect if it was due to rounding. What gives?

System info:
Linux 3.10.0-1160.71.1.el7.x86_64 #1 SMP Wed Jun 15 08:55:08 UTC 2022

Command info:
date (GNU coreutils) 8.22
bc 1.06.95
Python 2.7.5
perl 5, version 16, subversion 3 (v5.16.3) built for x86_64-linux-thread-multi

deleted 47 characters in body

Source Link

edited Sep 8, 2022 at 20:22

The Poopsmith

Source Link

asked Sep 8, 2022 at 20:13

The Poopsmith