even elder races get tired of waiting

even elder races get tired of waiting

[Emanuel Berg via Users list for the GNU Emacs text editor]

;;; this file:
;;;   http://user.it.uu.se/~embe8573/emacs-init/time-cmp.el
;;;   https://dataswamp.org/~incal/emacs-init/time-cmp.el

;; ...

(require 'cl-lib)
(defun days-from-date (d1 d2)
  (let*((sep     "-")
        (d1-data (cl-map 'list #'string-to-number (split-string d1 sep)))
        (d2-data (cl-map 'list #'string-to-number (split-string d2 sep)))
        (y1      (car   d1-data))
        (m1      (cadr  d1-data))
        (d1      (caddr d1-data))
        (y2      (car   d2-data))
        (m2      (cadr  d2-data))
        (d2      (caddr d2-data)) )
    (days-from y1 m1 d1 y2 m2 d2) ))
;; (days-from-date "2021-03-19" "2021-04-20") ; 31

(defun days-from (y1 m1 d1 y2 m2 d2)
  (let*((s-then (float-time (encode-time 0 0 0 d1 m1 y1)))
        (s-now  (float-time (encode-time 0 0 0 d2 m2 y2)))
        (s-diff (- s-now s-then)) )
    (string-to-number (format-seconds "%d" s-diff) )))
;; (days-from 2021 03 19 2021 04 20) ; 31

-- 
underground experts united
http://user.it.uu.se/~embe8573
https://dataswamp.org/~incal

Re: even elder races get tired of waiting

[Jean Louis]

* Emanuel Berg via Users list for the GNU Emacs text editor <help-gnu-emacs@gnu.org> [2021-03-20 23:39]:
> ;;; this file:
> ;;;   http://user.it.uu.se/~embe8573/emacs-init/time-cmp.el
> ;;;   https://dataswamp.org/~incal/emacs-init/time-cmp.el
> 
> ;; ...
> 
> (require 'cl-lib)
> (defun days-from-date (d1 d2)
>   (let*((sep     "-")
>         (d1-data (cl-map 'list #'string-to-number (split-string d1 sep)))
>         (d2-data (cl-map 'list #'string-to-number (split-string d2 sep)))
>         (y1      (car   d1-data))
>         (m1      (cadr  d1-data))
>         (d1      (caddr d1-data))
>         (y2      (car   d2-data))
>         (m2      (cadr  d2-data))
>         (d2      (caddr d2-data)) )
>     (days-from y1 m1 d1 y2 m2 d2) ))
> ;; (days-from-date "2021-03-19" "2021-04-20") ; 31
> 
> (defun days-from (y1 m1 d1 y2 m2 d2)
>   (let*((s-then (float-time (encode-time 0 0 0 d1 m1 y1)))
>         (s-now  (float-time (encode-time 0 0 0 d2 m2 y2)))
>         (s-diff (- s-now s-then)) )
>     (string-to-number (format-seconds "%d" s-diff) )))
> ;; (days-from 2021 03 19 2021 04 20) ; 31

Great.

I use PostgreSQL for that, and there is difference one day:

(defun days-from (from-date to-date)
  "Returns days passed from FROM-DATE to TO-DATE in format YYYY-MM-DD."
  (string-to-number
   (string-trim
    (shell-command-to-string
     (format "psql -Aqtc \"SELECT abs('%s'::date - '%s'::date)\"" to-date from-date)))))

(days-from "2021-03-19" "2021-04-20") => 32

Also here they claim to be 32:
https://www.timeanddate.com/date/durationresult.html?d1=19&m1=03&y1=2021&d2=20&m2=04&y2=2021

And if I click on that website [X] Include end date in calculation, I
get 33. Maybe website is wrong.

Human review:

     March 2021             April 2021     
Su Mo Tu We Th Fr Sa   Su Mo Tu We Th Fr Sa
    1  2  3  4  5  6                1  2  3
 7  8  9 10 11 12 13    4  5  6  7  8  9 10
14 15 16 17 18 19 20   11 12 13 14 15 16 17
21 22 23 24 25 26 27   18 19 20 21 22 23 24
28 29 30 31            25 26 27 28 29 30   

20 21 22 23 24 25 26 27 28 29 30 31 plus 20 = 32

So it is maybe matter of counting. I don't count the first day, as
that is like zero. But I do count last day. Website says 33 if last
day is counted.

So in the end your difference of 31 is maybe right.

Jean

Re: even elder races get tired of waiting

[Jean Louis]

But again, dates are not numbers:

Like 3 apples minus 1 apple is clearly 2.

But the difference between the date like 2021-03-23 and 2021-03-21 is
then 1 day. Date is not a number, neither a volume of something.

I am confused.

If we ask how many days are from Monday to Friday, we get into various
possible estimates:

1. To count the difference from the begin of Monday to begin of Friday
   making it full 4 days.

2. To count the difference from the end of Monday to begin of Firday,
   making it 3 day only

3. To count the difference from the begin of Monday to end of Friday,
   making it full 5 days.

4. Or to count the difference between the end of Monday to end of
   Friday making it 4 days.

I said I am confused, I have no idea how humans do those calculations
and now do not know what is right or wrong.

Then when I tell them something like:

"The first day of production could be, under all the conditions and
requirements, after 40 days upon the registration of the company and
your arrival. So, you could imagine that you could start getting first
products 24th May 2021."

then I can also assume that other humans who read such statements are
not going to verify discrepancies.

Thus we can safely rely on human error for the results of our
functions calculating day differences to be correct in any case.

Jean

Re: even elder races get tired of waiting

[Jude DaShiell]

Usually when this kind of question comes up it's in connection with 
business and close of business on given days.  So business open on monday 
to close of business on Friday given it's the same week would be 5 days.

Re: even elder races get tired of waiting

[Emanuel Berg via Users list for the GNU Emacs text editor]

Jude DaShiell wrote:

> Usually when this kind of question comes up it's in
> connection with business and close of business on given
> days. So business open on monday to close of business on
> Friday given it's the same week would be 5 days.

OK? And days start at 00:00?

-- 
underground experts united
http://user.it.uu.se/~embe8573
https://dataswamp.org/~incal

Re: even elder races get tired of waiting

[Jean Louis]

* Emanuel Berg via Users list for the GNU Emacs text editor <help-gnu-emacs@gnu.org> [2021-03-21 20:11]:
> Jude DaShiell wrote:
> 
> > Usually when this kind of question comes up it's in
> > connection with business and close of business on given
> > days. So business open on monday to close of business on
> > Friday given it's the same week would be 5 days.
> 
> OK? And days start at 00:00?

Good question!

There are few definitions for days, some definitions will say it
starts at zero, some others will tell it is interval of 24 hours, not
necessarily starting at zero, and some definition will speak of
daylight period.

So if business starts on Monday 08:00 o'clock -- or maybe in Sweden at
09:30 o'clock (they have have time...) and it maybe closes at 16
o'clock or in Sweden maybe 18:00 o'clock, then we have interval from

Monday 08:00 o'clock to Friday 18:00 o'clock Swedish opening hours,
that yields result of:

SELECT '2021-03-26 18:00'::timestamp - '2021-03-22 08:00'::timestamp;

    ?column?     
-----------------
 4 days 10:00:00

(time-from-to "2021-03-22 08:00" "2021-03-26 18:00") => 4 days 10:00:00

(defun time-from-to (from-date to-date)
  "Returns days passed from FROM-DATE to TO-DATE in format YYYY-MM-DD."
   (string-trim
    (shell-command-to-string
     (format "psql -Aqtc \"SELECT '%s'::timestamp - '%s'::timestamp;\"" to-date from-date))))

But then again it may be deceptive, we did not calculate working
hours, rather full difference, as worker did not work really 4 days
and 10 hours, but rather maybe 8 hours x 5 = 40 hours, which equals to
some 1.6 full days in a week.

There are 365 days in a year, 52 weeks, one month or 4 weeks is
usually some kind of holiday, there are maybe few more holidays. 48
weeks x 1.6 full days yields with actual work of 77 days in a year of
365 years, just 21% of the year time, and then so many will keep
complaining for overwork and whatever other reasons.

We are lazy.

Re: even elder races get tired of waiting

[Emanuel Berg via Users list for the GNU Emacs text editor]

Jean Louis wrote:

> Good question!
>
> So if business starts on Monday 08:00 o'clock -- or maybe in
> Sweden [...] We are lazy.

have you been smoking some weed in sweeden

-- 
underground experts united
http://user.it.uu.se/~embe8573
https://dataswamp.org/~incal

Re: even elder races get tired of waiting

[Jean Louis]

* Emanuel Berg via Users list for the GNU Emacs text editor <help-gnu-emacs@gnu.org> [2021-03-21 20:40]:
> Jean Louis wrote:
> 
> > Good question!
> >
> > So if business starts on Monday 08:00 o'clock -- or maybe in
> > Sweden [...] We are lazy.
> 
> have you been smoking some weed in sweeden

It was always wild and exciting without it, including in smaller towns
like Uddevalla.

Re: even elder races get tired of waiting

[Emanuel Berg via Users list for the GNU Emacs text editor]

>> OK? And days start at 00:00?
>
> Good question!
>
> There are few definitions for days, some definitions will
> say it starts at zero, some others will tell it is interval
> of 24 hours, not necessarily starting at zero, and some
> definition will speak of daylight period. [...]

How do you suggest I improve the function?

;;; -*- lexical-binding: t -*-
;;;
;;; this file:
;;;   http://user.it.uu.se/~embe8573/emacs-init/time-cmp.el
;;;   https://dataswamp.org/~incal/emacs-init/time-cmp.el

;; ...

(require 'cl-lib)
(defun days-from-date (d1 d2)
  (let*((sep     "-")
        (d1-data (cl-map 'list #'string-to-number (split-string d1 sep)))
        (d2-data (cl-map 'list #'string-to-number (split-string d2 sep)))
        (y1      (car   d1-data))
        (m1      (cadr  d1-data))
        (d1      (caddr d1-data))
        (y2      (car   d2-data))
        (m2      (cadr  d2-data))
        (d2      (caddr d2-data)) )
    (days-from y1 m1 d1 y2 m2 d2) ))
;; (days-from-date "2021-03-19" "2021-04-20") ; 31

(defun days-from (y1 m1 d1 y2 m2 d2)
  (let*((s-then (float-time (encode-time 0 0 0 d1 m1 y1)))
        (s-now  (float-time (encode-time 0 0 0 d2 m2 y2)))
        (s-diff (- s-now s-then)) )
    (string-to-number (format-seconds "%d" s-diff) )))
;; (days-from 2021 03 19 2021 04 20) ; 31

;; ...

-- 
underground experts united
http://user.it.uu.se/~embe8573
https://dataswamp.org/~incal

Re: even elder races get tired of waiting

[Jean Louis]

* Emanuel Berg via Users list for the GNU Emacs text editor <help-gnu-emacs@gnu.org> [2021-03-22 01:31]:
> >> OK? And days start at 00:00?
> >
> > Good question!
> >
> > There are few definitions for days, some definitions will
> > say it starts at zero, some others will tell it is interval
> > of 24 hours, not necessarily starting at zero, and some
> > definition will speak of daylight period. [...]
> 
> How do you suggest I improve the function?

Maybe you should first define what is meant with `days-from-date'. I
like that type of functions and I was looking for that in pure Emacs
lisp, and found the same what you already implemented that it could be
possible to calculate with dates and get differences. Yet I am still
sticking to external PostgreSQL based solutions.

Your function brought me to thinking and I am still confused if I was
calculating well the periods of time from one to other date, but no
human so far complained, that is why I said that human error makes the
functions work any way.

If you wish to say that `days-from-date' is calculated purely
mathematically, then what is the meaning of "from date", does it
include the date or it starts after the date? We have seen how humans
calculate "from date" often by including the date, like in:

In "We work from Monday to Friday" the expression "from" and "to"
includes both the beginning day and the ending day.

Because of so much ambiguity you would need to define what
`days-from-date' is meant to represent. 

(require 'cl-lib)
(defun days-from-date (d1 d2)
  (let*((sep     "-")
        (d1-data (cl-map 'list #'string-to-number (split-string d1 sep)))
        (d2-data (cl-map 'list #'string-to-number (split-string d2 sep)))
        (y1      (car   d1-data))
        (m1      (cadr  d1-data))
        (d1      (caddr d1-data))
        (y2      (car   d2-data))
        (m2      (cadr  d2-data))
        (d2      (caddr d2-data)) )
    (days-from y1 m1 d1 y2 m2 d2) ))
;; (days-from-date "2021-03-19" "2021-04-20") ; 31

Gives me 32 now.

(defun days-from (y1 m1 d1 y2 m2 d2)
  (let*((s-then (float-time (encode-time 0 0 0 d1 m1 y1)))
        (s-now  (float-time (encode-time 0 0 0 d2 m2 y2)))
        (s-diff (- s-now s-then)) )
    (string-to-number (format-seconds "%d" s-diff) )))
;; (days-from 2021 03 19 2021 04 20) ; 31

Now the above gives me 32 in this moment March 22 10:40 EAT, how
comes? It was giving me 31 before.

Re: even elder races get tired of waiting

[Emanuel Berg via Users list for the GNU Emacs text editor]

Jean Louis wrote:

> Maybe you should first define what is meant with
> `days-from-date'. [...]

OK, well, hit me then, what should the definition be?

This is for practical use, how many days till my date with
Sandra Bullock - because maybe some things need to be
arranged? ... No? Okay, bad example

But it is also data for the sake of date because it is
interesting at least to a "datadyrkare" like me
(untranslatable Swedish pun), e.g. I did
"Artificial Intelligence" at Uppsala University 2012-05-30,
that was 8y 9m 20d ago.

Now I used 'time-from' (zsh, not Elisp) BTW [1]

> (require 'cl-lib)
> (defun days-from-date (d1 d2)
>   (let*((sep     "-")
>         (d1-data (cl-map 'list #'string-to-number (split-string d1 sep)))
>         (d2-data (cl-map 'list #'string-to-number (split-string d2 sep)))
>         (y1      (car   d1-data))
>         (m1      (cadr  d1-data))
>         (d1      (caddr d1-data))
>         (y2      (car   d2-data))
>         (m2      (cadr  d2-data))
>         (d2      (caddr d2-data)) )
>     (days-from y1 m1 d1 y2 m2 d2) ))
> ;; (days-from-date "2021-03-19" "2021-04-20") ; 31
>
> Gives me 32 now.

? 31!

> (defun days-from (y1 m1 d1 y2 m2 d2)
>   (let*((s-then (float-time (encode-time 0 0 0 d1 m1 y1)))
>         (s-now  (float-time (encode-time 0 0 0 d2 m2 y2)))
>         (s-diff (- s-now s-then)) )
>     (string-to-number (format-seconds "%d" s-diff) )))
> ;; (days-from 2021 03 19 2021 04 20) ; 31
>
> Now the above gives me 32 in this moment March 22 10:40 EAT,
> how comes? It was giving me 31 before.

31! ??? Glitch in the Matrix?

    <incal> are we a simulation? well, if you in the future
            can do a simulation as good as this/we, let's call
            it s1
    <incal> then you can obviously do s2 ... sn as well
    <incal> where n -> (inf.)
    <incal> that many? yes, because the simulations will soon
            do simulations themselves!
    <incal> so the probability we are The Real McCoy is s -> 0+
    <incal> in practice zero
    <incal> now tell me, what IS wrong with this reasoning?

[1] https://dataswamp.org/~incal/conf/.zsh/time

-- 
underground experts united
http://user.it.uu.se/~embe8573
https://dataswamp.org/~incal

Re: even elder races get tired of waiting

[Jean Louis]

* Emanuel Berg via Users list for the GNU Emacs text editor <help-gnu-emacs@gnu.org> [2021-03-22 21:30]:
> Jean Louis wrote:
> 
> > Maybe you should first define what is meant with
> > `days-from-date'. [...]
> 
> OK, well, hit me then, what should the definition be?
> 
> This is for practical use, how many days till my date with
> Sandra Bullock - because maybe some things need to be
> arranged? ... No? Okay, bad example

Is good example, would we be 30 years back in time. (This way the
warriors will not easily get a clue.)

> But it is also data for the sake of date because it is
> interesting at least to a "datadyrkare" like me
> (untranslatable Swedish pun), e.g. I did
> "Artificial Intelligence" at Uppsala University 2012-05-30,
> that was 8y 9m 20d ago.

For that I use `age' that again uses PostgreSQL:

(defun age (date)
  "Returns the age by using PostgreSQL. It is usable to find out
the age of people"
  (let* ((command (format "psql -Stc \"SELECT age(date('%s'));\"" date))
	 (age (shell-command-to-string command))
	 (age (string-trim age))
	 (age (replace-regexp-in-string " mon " " month " age))
	 (age (replace-regexp-in-string " mons " " months " age)))
    age))

(age "2012-05-30") → 8 years 9 months 23 days

I do trust the PostgreSQL and that would mean you have lost somewhere
those 3 days, who knows, maybe with Sandra in sauna.

> Now I used 'time-from' (zsh, not Elisp) BTW [1]

Maybe there is some bug in their function.

> 31! ??? Glitch in the Matrix?

I would not know any more, I have given you truthful evaluation on my
side. I was thinking maybe at specific time of the day it would show
one day more or less, and that it was that what is happening. Because
your function is not well understood on my side, I am simply skipping
it and relying on PostgreSQL calls.

> [1] https://dataswamp.org/~incal/conf/.zsh/time

> "Artificial Intelligence" at Uppsala University 2012-05-30,

$ datediff -f '%Yy %mm %dd %Hh %Mmin %Ss' 2012-05-30 2021-03-22 yields
  8y 9m 20d 0h 0min 0s and I understand that, but you lost somewhere 3
  days.

  Maybe you are discovering now bug in dateutils, or bug in PostgreSQL
  -- I just don't believe the latter.

  Leap years were 2020, 2016, maybe some days are missing because of
  that.

Jean

Re: even elder races get tired of waiting

[Emanuel Berg via Users list for the GNU Emacs text editor]

Jean Louis wrote:

>> This is for practical use, how many days till my date with
>> Sandra Bullock [...]
>
> Is good example, would we be 30 years back in time. (This
> way the warriors will not easily get a clue.)

HA!

But Good "Old" Sandy (born 1964-07-26) was the highest-paid
actress in 2010 and 2014 [1] so perhaps she can afford to buy
really exclusive food, at least? Then again, while I'm not
always the perfect gentleman I am gentleman enough to not have
the dame pay the bill on a date... No, all of this will have
to be postponed until after my upcoming employment of the
fort-knox.el script...

> For that I use `age' that again uses PostgreSQL:
>
> (defun age (date)
>   "Returns the age by using PostgreSQL. It is usable to find out
> the age of people"

Maybe ... if that's what happens ;)

>   (let* ((command (format "psql -Stc \"SELECT age(date('%s'));\"" date))
> 	 (age (shell-command-to-string command))
> 	 (age (string-trim age))
> 	 (age (replace-regexp-in-string " mon " " month " age))
> 	 (age (replace-regexp-in-string " mons " " months " age)))
>     age))
>
> I do trust the PostgreSQL and that would mean you have lost
> somewhere those 3 days, who knows, maybe with Sandra
> in sauna.

This is getting too confusing...

OK, but let's stick to Sandra, I know that is an foreign
concept in your part of the world but bear with me. How old is
she? What do you get with PostgreSQL?

I get:

Lisp: [2]

(time-from 1964 07 26 0 0 0 2021 03 22 0 0 0) ; 56y 253d 0h 0m 0s [1]

zsh/dateutils.ddiff: [3]

$ time-from 1964-07-26
56y 7m 24d 0h 0min 0s

(Oh, no, now I see, not even normalized output format...)

[1] https://en.wikipedia.org/wiki/Sandra_bullock
[2] https://dataswamp.org/~incal/emacs-init/time-cmp.el
[3] https://dataswamp.org/~incal/conf/.zsh/time

-- 
underground experts united
http://user.it.uu.se/~embe8573
https://dataswamp.org/~incal

Re: even elder races get tired of waiting

[Jean Louis]

* Emanuel Berg via Users list for the GNU Emacs text editor <help-gnu-emacs@gnu.org> [2021-03-22 22:49]:
> OK, but let's stick to Sandra, I know that is an foreign
> concept in your part of the world but bear with me. How old is
> she? What do you get with PostgreSQL?
> 
> I get:
> 
> Lisp: [2]
> 
> (time-from 1964 07 26 0 0 0 2021 03 22 0 0 0) ; 56y 253d 0h 0m 0s [1]
> 
> zsh/dateutils.ddiff: [3]
> 
> $ time-from 1964-07-26
> 56y 7m 24d 0h 0min 0s
> 
> (Oh, no, now I see, not even normalized output format...)

(age "1964-07-26") → 56 years 7 months 27 days

Now we can see that not only you miss 3 days, she misses three days as
well, maybe it was the sauna.

Jean

P.S. Who is right, PostgreSQL or diffutils?

Re: even elder races get tired of waiting

[Emanuel Berg via Users list for the GNU Emacs text editor]

Jean Louis wrote:

>> I get:
>> 
>> Lisp:
>> 
>> (time-from 1964 07 26 0 0 0 2021 03 22 0 0 0) ; 56y 253d 0h 0m 0s
>> 
>> zsh/dateutils.ddiff:
>> 
>> $ time-from 1964-07-26
>> 56y 7m 24d 0h 0min 0s
>> 
>> (Oh, no, now I see, not even normalized output format...)
>
> (age "1964-07-26") → 56 years 7 months 27 days
>
> Now we can see that not only you miss 3 days, she misses
> three days as well, maybe it was the sauna.
>
> Jean
>
> P.S. Who is right, PostgreSQL or diffutils?

Let's see ... don't we have any software to answer
that question? :)

The Lisp [1] cannot be easily normalized because `format-seconds'
do years and seconds but not months:

  Use format control STRING to format the number SECONDS.
  The valid format specifiers are:
  %y is the number of (365-day) years.
  %d is the number of days.
  %h is the number of hours.
  %m is the number of minutes.
  %s is the number of seconds.
  %z is a non-printing control flag (see below).
  %% is a literal "%".

Do it all into days only? Then I can use my other Lisp [same
file]

  (days-from-date "1964-07-26" "2021-03-22") ; 20693

And the zsh [2]

  $ time-from 1964-07-26
  56y 7m 24d 0h 0min 0s (20693 days)

and... *drumroll*

  (= 20693 20693) ; t

Oh no Jean, this doesn't look good for you :)

[1] https://dataswamp.org/~incal/emacs-init/time-cmp.el
[2] https://dataswamp.org/~incal/conf/.zsh/time

-- 
underground experts united
http://user.it.uu.se/~embe8573
https://dataswamp.org/~incal

Re: even elder races get tired of waiting

[Emanuel Berg via Users list for the GNU Emacs text editor]

> And the zsh
>
>   $ time-from 1964-07-26
>   56y 7m 24d 0h 0min 0s (20693 days)
>
> and... *drumroll*
>
>   (= 20693 20693) ; t
>
> Oh no Jean, this doesn't look good for you :)

Wait - I know what it is - for the love of God, did we ever
even SYNCHRONIZE OUR DAMN CLOCKS?

hahaha :D

-- 
underground experts united
http://user.it.uu.se/~embe8573
https://dataswamp.org/~incal

Re: even elder races get tired of waiting

[Jean Louis]

* Emanuel Berg via Users list for the GNU Emacs text editor <help-gnu-emacs@gnu.org> [2021-03-23 00:34]:
> Jean Louis wrote:
> 
> >> I get:
> >> 
> >> Lisp:
> >> 
> >> (time-from 1964 07 26 0 0 0 2021 03 22 0 0 0) ; 56y 253d 0h 0m 0s
> >> 
> >> zsh/dateutils.ddiff:
> >> 
> >> $ time-from 1964-07-26
> >> 56y 7m 24d 0h 0min 0s
> >> 
> >> (Oh, no, now I see, not even normalized output format...)
> >
> > (age "1964-07-26") → 56 years 7 months 27 days
> >
> > Now we can see that not only you miss 3 days, she misses
> > three days as well, maybe it was the sauna.
> >
> > Jean
> >
> > P.S. Who is right, PostgreSQL or diffutils?
> 
> Let's see ... don't we have any software to answer
> that question? :)
> 
> The Lisp [1] cannot be easily normalized because `format-seconds'
> do years and seconds but not months:
> 
>   Use format control STRING to format the number SECONDS.
>   The valid format specifiers are:
>   %y is the number of (365-day) years.
>   %d is the number of days.
>   %h is the number of hours.
>   %m is the number of minutes.
>   %s is the number of seconds.
>   %z is a non-printing control flag (see below).
>   %% is a literal "%".
> 
> Do it all into days only? Then I can use my other Lisp [same
> file]
> 
>   (days-from-date "1964-07-26" "2021-03-22") ; 20693
> 
> And the zsh [2]
> 
>   $ time-from 1964-07-26
>   56y 7m 24d 0h 0min 0s (20693 days)
> 
> and... *drumroll*
> 
>   (= 20693 20693) ; t
> 
> Oh no Jean, this doesn't look good for you :)

Hmm:

$ date --utc -d 'jul 7 1964 +56years +7months +24days'
  Wed Mar  3 12:00:00 AM UTC 2021

I am not sure if you have tested it on Monday or Tuesday, today.

Your function was showing yesterday Monday the difference of 56 years,
7 months and 24 days from 1964-07-26, but `date' command tells that
difference comes tomorrow, Wednesday.

That is discrepancy to my result from PostgreSQL and your result with
datediff.

We have to find solution that works, as no Sandra wants to be called
older than she is.

Jean

Re: even elder races get tired of waiting

[Emanuel Berg via Users list for the GNU Emacs text editor]

Jean Louis wrote:

> Hmm:
>
> $ date --utc -d 'jul 7 1964 +56years +7months +24days'
>   Wed Mar  3 12:00:00 AM UTC 2021
>
> I am not sure if you have tested it on Monday or
> Tuesday, today.

The date header will tell you. But it was yesterday.

Actually that is even explicit in the Elisp:

    (days-from-date "1964-07-26" "2021-03-22") ; 20693

I can make the zsh explicit as well since the second argument
is optional (and defaults to today, i.e. that was yesterday
yesterday, when it was invoked)

But OK let's do it again explicitly explicitly this time:

  time-from 1964-07-26 2021-03-22
  56y 7m 24d 0h 0min 0s (20693 days)

So it is still the same, 20 693 days.

> We have to find solution that works, as no Sandra wants to
> be called older than she is.

Not even by 3 days :)

No, Sandra is 20 693 days, two methods show the same result.
Unless they use the same source, that counts as a theoretical
proof in the math university world.

-- 
underground experts united
http://user.it.uu.se/~embe8573
https://dataswamp.org/~incal

Re: even elder races get tired of waiting

[Jean Louis]

* Emanuel Berg via Users list for the GNU Emacs text editor <help-gnu-emacs@gnu.org> [2021-03-23 00:34]:
> Let's see ... don't we have any software to answer
> that question? :)

qalculate says there can be various basis to calculate it:

Basis is the type of day counting you want to use: 0: US 30/360, 1:
real days (default), 2: real days/360, 3: real days/365 or 4: European
30/360.

More references about day-count conventions:
https://financetrain.com/30e360-day-count-convention-eurobond-basis/
https://www.investopedia.com/terms/d/daycount.asp

Re: even elder races get tired of waiting

[Emanuel Berg via Users list for the GNU Emacs text editor]

Jean Louis wrote:

>> Let's see ... don't we have any software to answer that
>> question? :)
>
> qalculate says there can be various basis to calculate it:
>
> Basis is the type of day counting you want to use: 0: US
> 30/360, 1: real days (default), 2: real days/360, 3: real
> days/365 or 4: European 30/360.

Emacs and dateutils got it to something, whatever it is it is
the same, I'm sure they considered every scenario including
Hollywood actresses' photogenicity and female sensitivity
regarding age before arriving at the same solution, what the
Postgres guys are up to I wonder but they are scoring low
points as it stands what I can see.

-- 
underground experts united
http://user.it.uu.se/~embe8573
https://dataswamp.org/~incal

Re: even elder races get tired of waiting

[Jean Louis]

Another reference to how to count days:
https://answers.yahoo.com/question/index?qid=20130223140438AAJ4V5I

As if mother says that teenager is grounded until 23rd, that would
include the 23rd most probably, but mathematically not.

That is why our Emacs Lisp functions shall be clear in their
descriptions what is meant with it and maybe include wordings such as
"up to and including the 23rd" or "through the 23rd"

Re: even elder races get tired of waiting

[Emanuel Berg via Users list for the GNU Emacs text editor]

Jean Louis wrote:

> That is why our Emacs Lisp functions shall be clear in their
> descriptions what is meant with it and maybe include
> wordings such as "up to and including the 23rd" or "through
> the 23rd"

Yes but again what definition is the most useful in terms of
usability?

And what is the most true in terms of data?

And are those the same or two different?

-- 
underground experts united
http://user.it.uu.se/~embe8573
https://dataswamp.org/~incal

Re: even elder races get tired of waiting

[Jean Louis]

* Emanuel Berg via Users list for the GNU Emacs text editor <help-gnu-emacs@gnu.org> [2021-03-22 21:41]:
> Jean Louis wrote:
> 
> > That is why our Emacs Lisp functions shall be clear in their
> > descriptions what is meant with it and maybe include
> > wordings such as "up to and including the 23rd" or "through
> > the 23rd"
> 
> Yes but again what definition is the most useful in terms of
> usability?

In terms of usability? I would not know how you use it. It is obvious
you do not use function as I use it to calculate and insert the
descriptive timeline as text where various tasks and their periods are
calculated. My timeline is in my opinion more practical, as if I need
4 days for a task and we start on Monday, 1 day ends on Tuesday, 2
days on Wednesday, 3 on Thursday and we complete the task on Friday as
that is Monday plus 4 days.

Monday 10 o'clock is start
Tuesday 10 is 1st day
Wednesday 10 is 2nd day
Thursday 10 is 3rd day
Friday 10 is 4th day and task is completed. But we do not specify
times.

Maybe you should call your function day-mathematical-difference if it
calculates what is difference between days mathematically. I am also
confused. And I do not know how your function works. It looks like
magic for now.

> And what is the most true in terms of data?

To eliminate ambiguity it is best to speak of hours and seconds, as
then it becomes possible to add, reduce, find differences between
time stamps, instead of dates. Internally those dates are sometimes
counted as time stamps, but maybe not, depends of language. If you do
have specific time stamp with seconds then it becomes easier to see
how much time passed.

If you say "days from 1st January", we do not know if you count it
from 1st January 0 o'clock or 1st January 24 o'clock, we also cannot
know if you count "now" as March 22nd 0 o'clock or March 22nd 22:20
o'clock, or maybe March 22nd 24 o'clock. Eliminate those ambiguities
and difference will become mathematically clear.

> And are those the same or two different?

If I would just know what we talk about...

Jean

Re: even elder races get tired of waiting

[Jean Louis]

* Jude DaShiell <jdashiel@panix.com> [2021-03-21 18:13]:
> Usually when this kind of question comes up it's in connection with business
> and close of business on given days.  So business open on monday to close of
> business on Friday given it's the same week would be 5 days.

Yes, when it is so practical it has clear meaning.

On my side I am using periods of time to estimate completion dates.

From 21st to 22nd is definitely one day, but we did not say when is
begin and when is end exactly.

SELECT DATE(DATE '2021-03-21' + interval '1 days');

    date    
------------
 2021-03-22

then from this SQL result I can see that result deducted from Friday
12th for 5 days yields 7th March at 00:00 o'clock, so then I can think
that in that case Friday was not calculated, I can assume calculation
was from Friday 00:00 o'clock, it does not include full Friday.

Friday deducted for 5 days does not yield Monday, it yields Sunday
00:00 o'clock. 

SELECT '2021-03-12'::date - interval '5 days';
      ?column?       
---------------------
 2021-03-07 00:00:00

Thus computers must start from somewhere, when computer is asked how
much is Friday deducted for 5 days, the answer will be Sunday, 00:00
o'clock.

Human will say that 5 days work from Monday ends on Friday, there is
no Sunday involved.

Re: even elder races get tired of waiting

[Jude DaShiell]

Use of cal with a month number and a year number to get a weekday of a 
particular date can make work a little easier.
This is for really long time periods and only inside the gregorian 
calendar constraints since outside of those constraints things get really 
wild as a result of compound errors.
With that weekday in mind subtracting a year when you won't land in a leap 
year or adding a year when you won't land in a leap year, subtract or add 
one weekday to get the correct weekday for that date in those years.  If 
you will land in a leap year, subtract or add two weekdays to get the 
correct weekday.  Modulus the weekday by 7 to keep it in whichever range 
you prefer to use..
That can get you to the correct forest, then it's a matter of smaller 
subtraction or addition within a year to get you your exact length.

Re: even elder races get tired of waiting

[Emanuel Berg via Users list for the GNU Emacs text editor]

Jude DaShiell wrote:

> Use of cal [...]

Screenshot:
  https://dataswamp.org/~incal/pimgs/gcal.png

#! /bin/zsh
#
# this file:
#   http://user.it.uu.se/~embe8573/conf/.zsh/cal
#   https://dataswamp.org/~incal/conf/.zsh/cal

export GCAT_HI='\e[47;30m:\e[0m:\e[01;31m:\e[0m'

alias c='date +"                   %m"; gch'

gc () {
    gcal                      \
        --force-highlighting  \
        -H $GCAT_HI           \
        -q SE                 \
        -s 1 | \grep .
}

gch () {
    local month=${1:-$(date +'%m')}

    gcal                      \
        --force-highlighting  \
        -G                    \
        -H $GCAT_HI           \
        -N                    \
        -q SE                 \
        -s 1                  \
        -X                    \
        $month           |
        \grep .          |
        cut -d '(' -f 1  |
        sed -e "s/New Year's Day/nyårsdagen/"                     \
            -e "s/Epiphany\/Three King's Day/trettondedag jul/"   \
            -e "s/Good Friday/långfredagen/"                      \
            -e "s/Easter Sunday/påskdagen/"                       \
            -e "s/Easter Monday/annandag påsk/"                   \
            -e "s/May Day/första maj/"                            \
            -e "s/Christ's Ascension Day/kristi himmelfärdsdag/"  \
            -e "s/Whitsunday\/Pentecost/pingstdagen/"             \
            -e "s/National Holiday/nationaldagen/"                \
            -e "s/All Saints' Day/alla helgons dag/"              \
            -e "s/Christmas Day/juldagen/"                        \
            -e "s/Boxing Day/annandag jul/"
}

# also, 2020-06-20: midsommardagen
# https://www.kalender.se/helgdagar

-- 
underground experts united
http://user.it.uu.se/~embe8573
https://dataswamp.org/~incal

Re: even elder races get tired of waiting

[Jean Louis]

* Jude DaShiell <jdashiel@panix.com> [2021-03-21 22:24]:
> Use of cal with a month number and a year number to get a weekday of a
> particular date can make work a little easier.

How to do that?

> This is for really long time periods and only inside the gregorian calendar
> constraints since outside of those constraints things get really wild as a
> result of compound errors.
> With that weekday in mind subtracting a year when you won't land in a leap
> year or adding a year when you won't land in a leap year, subtract or add
> one weekday to get the correct weekday for that date in those years.  If you
> will land in a leap year, subtract or add two weekdays to get the correct
> weekday.  Modulus the weekday by 7 to keep it in whichever range you prefer
> to use..

I would like to use Emacs functions to calculate the new DATE after
SOME NUMBER OF DAYS from STARTING DATE.

For leap years it looks like PostgreSQL isdoing it right:

(defun days-from (from-date to-date)
  "Returns days passed from FROM-DATE to TO-DATE in format YYYY-MM-DD."
  (string-to-number
   (string-trim
    (shell-command-to-string
     (format "psql -Aqtc \"SELECT abs('%s'::date - '%s'::date)\"" to-date from-date)))))

(days-from "2020-02-28" "2020-03-01") => 2
(days-from "2021-02-28" "2021-03-01") => 1