Hello.

I would like to share my `datediff.sh' script.

The script takes two dates and calculates time intervals between them in various units of time.

The fun is that it uses bash arithmetics and `bc' to perform calculations. If available, `BSD/GNU date' programme is warped to interpret date inputs, however the script works without package `date' if input is ``ISO-8601 format''.

It took me a lot of hard work in the last two or so years to get the calculation to work correctly, but things started working better when I read Dershowitz and Reingold paper/book of Calendrical Calculations.

I would like to highlight datediff.sh can calculate a compound time interval, for example, the interval between some two dates may be `10 years + 2 months + 1 week + 10 hours', or you get single unit intervals, for example, `10.18 years' or `239.59 months' and so forth.

The compound time range code was pretty hard to write, specially what Hroptatyr calls `Refinement Rules'. But also, I was able to implement support for time offset and envar $TZ into the calculation. It can even generate the Unix time stamp and day of the week (RFC-5322) of the dates independently with shell arithmetics!

I hope this script may be useful as it works with bash 2.05b+ versions. The script is really complex but I reckon I have finished developing it (i.e. I don't reckon there is anything else I need it do). It is well tested with millions of dates and the core code seems quite stable, IMHO.

If someone can find any bugs or shed advice for improvement, I would hear it.

The ``datediff.sh'' script is published in GitHub at: github [dot] com/mountaineerbr/scripts

Below is a copy (hopefully formatting is preserved!).
###

#!/usr/bin/env bash
# datediff.sh - Calculate time ranges between dates
# v0.20 nov/2022 mountaineerbr GPLv3+
shopt -s extglob #bash2.05b+

HELP="NAME
${0##*/} - Calculate time ranges/intervals between dates

SYNOPSIS
${0##*/} [-NUM] [-Rrttuvvv] [-f\"FMT\"] \"DATE1\" \"DATE2\" [UNIT]
${0##*/} -[el] [-v] YEAR..
${0##*/} -h

DESCRIPTION
Calculate time intervals between DATE1 and DATE2 or check for leap
years. The \`date' programme is optionally run to process dates.

\`GNU date' accepts mostly free format human readable date strings.
If using \`FreeBSD date', input DATE strings must be ISO-8601,
\`YYYY-MM-DDThh:mm:ss' unless option \`-f FMT' is set to a new
input time format. If \`date' programme is not available then input
must be ISO-8601 formatted.

If DATE is not set, defaults to \`now'. To flag DATE as UNIX time,
prepend an at sign \`@' to it or set option -r. Stdin input sup-
ports one DATE string per line (max two lines) or two ISO-8601
DATES separated by space in a single line. Input is processed in
a best effort basis.

Output RANGES section displays intervals in different units of
time (years or months or weeks or days or hours or minutes or
seconds alone). It also displays a compound time range with all
the above units into consideration to each other.

Single UNIT time periods can be displayed in table format -t and
their scale set with -NUM where NUM is an integer. Result least
significant digit is subject to rounding. When last positional
parameter UNIT is exactly one of \`Y', \`MO', \`W', \`D', \`H',
\`M' or \`S', only a single UNIT interval is printed.

Output DATE section prints two dates in ISO-8601 format or, if
option -R is set, RFC-5322 format.

Option -e prints Easter date for given YEARs.

Option -l checks if YEAR is leap. Set option -v to decrease ver-
bose. ISO-8601 system assumes proleptic Gregorian calendar, year
zero and no leap seconds.

Option -u sets or prints dates in Coordinated Universal Time (UTC).

ISO-8601 DATE offset is supported throughout this script. When
environment \$TZ is a positive or negative decimal number, such
as \`UTC+3', it is read as offset. Variable \$TZ with timezone name
or ID (e.g. \`America/Sao_Paulo') is supported by \`date' programme.

This script uses Bash arithmetics to perform most time range cal-
culations, as long as input is a valid ISO-8601 date format.

Option -d sets \$TZ=UTC, unsets verbose switches and run checks
against \`datediff' and \`date' (dump only when results differ),
set twice to code exit only.

Option -D disables \`date' package warping and -DD disables bash
\`printf %()T' warping, too.

ENVIRONMENT
TZ Offset time. POSIX time zone definition by the \$TZ vari-
able takes a different form from ISO-8601 standards, so
that UTC-03 is equivalent to setting \$TZ=UTC+03. Only
the \`date' programme can parse timezone names and IDS.

REFINEMENT RULES
Some date intervals can be calculated in more than one way depend-
ing on the logic used in the \`compound time range' display. We
decided to mimic hroptatyr's \`datediff' refinement rules as often
as possible.

Script error rate of the core code is estimated to be lower than
one percent after extensive testing with selected and corner-case
sample dates and times. Check script source code for details.

SEE ALSO
\`Datediff' from \`dateutils', by Hroptatyr.
<www.fresse.org/dateutils/>

\`Units' from GNU.
<https://www.gnu.org/software/units/>

Do calendrical savants use calculation to answer date questions?
A functional magnetic resonance imaging study, Cowan and Frith, 2009.
<https://www.ncbi.nlm.nih.gov/pmc/articles/PMC2677581/#!po=21.1864>

Calendrical calculation, Dershowitz and Reingold, 1990
<http://www.cs.tau.ac.il/~nachum/papers/cc-paper.pdf>
<https://books.google.com.br/books?id=DPbx0-qgXu0C>

How many days are in a year? Manning, 1997.
<https://pumas.nasa.gov/files/04_21_97_1.pdf>

Iana Time zone database
<https://www.iana.org/time-zones>

Fun with Date Arithmetic (see replies)
<https://linuxcommando.blogspot.com/2009/11/fun-with-date-arithmetic.html>

Tip: Division is but subtractions and multiplication but additions.
--Lost reference

WARRANTY
Licensed under the GNU General Public License 3 or better. This
software is distributed without support or bug corrections.

Bash2.05b+ is required. \`Bc' is required for single-unit calcula-
tions. FreeBSD12+ or GNU \`date' is optionally required.

Please consider sending me a nickle!
=) bc1qlxm5dfjl58whg6tvtszg5pfna9mn2cr2nulnjr

EXAMPLES
Leap year check
$ ${0##*/} -l 2000
$ ${0##*/} -l {1980..2000}
$ echo 2000 | ${0##*/} -l

#Single unit time periods
$ ${0##*/} 2022-03-01T00:00:00 2022-03-01T10:10:10 m #(m)ins
$ ${0##*/} '10 years ago' mo #(mo)nths
$ ${0##*/} 1970-01-01 2000-02-02 y #(y)ears

Time ranges/intervals
$ ${0##*/} 2020-01-03T14:30:10 2020-12-24T00:00:00
$ ${0##*/} 0921-04-12 1999-01-31
$ echo 1970-01-01 2000-02-02 | ${0##*/}
$ TZ=UTC+3 ${0##*/} 2020-01-03T14:30:10-06 2021-12-30T21:00:10-03:20

\`GNU date' warping
$ ${0##*/} 'next monday'
$ ${0##*/} 2019/6/28 1Aug
$ ${0##*/} '5min 34seconds'
$ ${0##*/} 1aug1990-9month now
$ ${0##*/} -- -2week-3day
$ ${0##*/} -- \"today + 1day\" @1952292365
$ ${0##*/} -2 -- '1hour ago 30min ago'
$ ${0##*/} today00:00 '12 May 2020 14:50:50'
$ ${0##*/} '2020-01-01 - 6months' 2020-01-01
$ ${0##*/} '05 jan 2005' 'now - 43years -13 days'
$ ${0##*/} @1561243015 @1592865415

\`BSD date' warping
$ ${0##*/} -f'%m/%d/%Y' 6/28/2019 9/04/1970
$ ${0##*/} -r 1561243015 1592865415
$ ${0##*/} 200002280910.33 0003290010.00
$ ${0##*/} -- '-v +2d' '-v -3w'

OPTIONS
-[0-9] Set scale for single unit intervals.
-DDdd Debug, see help page text.
-e YEAR Print Easter date for given YEAR.
-f FMT Input time format string (only with BSD \`date').
-h Print this help page.
-l YEAR Check if YEAR is leap year.
-R Print human time in RFC-5322 format (verbose).
-r, -@ Input DATES are UNIX times.
-tt Table layout display of single unit intervals.
-u Set or print UTC time instead of local time.
-v Less verbose.
-vv Print only single unit ranges.
-vvv Print only compound range."

#TESTING RESULTS
#!# MAIN TESTING SCRIPT: <https://pastebin.com/suw4Bif3>
# Hroptatyr's `man datediff' says ``refinement rules'' cover over 99% cases.
# Calculated `datediff' error rate is at least .00311 (0.3%) of total tested dates (compound range).
# Results differ from `datediff' in .006275 (0,6%) of all tested dates in script version v0.16.8 (compound range).
# All differences occur with ``end-of-month vs. start-of-month'' dates, such as days `29, 30 or 31' of one date against days `1, 2 or 3' of the other date.
# Different results from `datediff' in compound range are not necessarily errors in all cases and may be considered correct albeit with different refinements. This seem to be the case for most, if not all, differences obtained in testing results.
# No errors were found in range (seconds) calculation, thus single-unit results should all be correct.
#!# OFFSET TESTING SCRIPT: <https://pastebin.com/BvH6PDjC>
# Note `datediff' offset ranges between -14h and +14h.
# All offset-aware date results passed checking against `datediff'.

On 10.11.2022 23:33, castAway wrote:
> Hello.
>
> I would like to share my `datediff.sh' script.

(Note that it's rather a datediff.bash script as presented.)

>
> The script takes two dates and calculates time intervals between them in
> various units of time.

What does the script that AT&T date or GNU date doesn't support in this
(time-intervals) respect?

Since I notice some mention of "easter"; which definitions of "easter"
does it support? (I presume you know that there's not a single one.)

Does your script support moon phases? (Something I recently looked for,
so I am curious.)

>
> The fun is that it uses bash arithmetics and `bc' to perform
> calculations. If available, `BSD/GNU date' programme is warped to
> interpret date inputs, however the script works without package `date'
> if input is ``ISO-8601 format''.

I don't get it. What's the point in using bash arithmetics and bc (or
only sometimes)? I mean it wouldn't occur to me that multi-precision
arithmetic would be necessary for that. For floating point arithmetic,
OTOH, I'd use ksh (instead of bash) and generally omit bc. (I just
noticed that you additionally use dc as well; the dc-code used in
easterf() looks horrible, for my taste, and quite unmaintainable as
presented.)

>
> It took me a lot of hard work in the last two or so years to get the
> calculation to work correctly, but things started working better when I
> read Dershowitz and Reingold paper/book of Calendrical Calculations.
>
> I would like to highlight datediff.sh can calculate a compound time
> interval, for example, the interval between some two dates may be `10
> years + 2 months + 1 week + 10 hours', or you get single unit intervals,
> for example, `10.18 years' or `239.59 months' and so forth.

Looks to me like the mentioned date programs or a simple GNU awk date
implementation supports that already.

>
> The compound time range code was pretty hard to write, specially what
> Hroptatyr calls `Refinement Rules'. But also, I was able to implement
> support for time offset and envar $TZ into the calculation. It can even
> generate the Unix time stamp and day of the week (RFC-5322) of the dates
> independently with shell arithmetics!

I used inherent TZ support already with dates used in scripts that use
GNU awk dates and in AT&T or ksh dates. Why do you mention TZ support
as something special here?

>
> I hope this script may be useful as it works with bash 2.05b+ versions.
> The script is really complex but I reckon I have finished developing it
> (i.e. I don't reckon there is anything else I need it do). It is well
> tested with millions of dates and the core code seems quite stable, IMHO.

You could have avoided unnecessary bash specifics to make your script
run on other prominent shells (ksh, zsh, or even sh) as well. (Some
changes are trivial, like local in functions.)

>
> If someone can find any bugs or shed advice for improvement, I would
> hear it.

I just skimmed through it and saw some strange constructs and comments;
e.g. "YYY-..." in a comment named ISO-date, or a $((++RET)) return value
with undefined and otherwise unused RET variable. (I know it works but
implementing side effects on undefined global scoped variables that
will change the return/exit code of a function cal every time, and will
at times overflow the allowed return value range is not something that
looks trustworthy to me.) There's a couple places where you use obsolete
constructs, mix legacy (-eq) and new syntax, or use unnecessary complex
expressions (e.g. (( (yearA||yearA==0) ... )) in arithmetic context).
There's probably a lot more to find given the huge size of that script.

Note that I've written my questions and comments because the script is
so large, partly confusing, and not that confidence-inspiring [to me].
Must have been a pain to write and debug that large piece of code. So
please don't take my hints and comments too serious. I'm just critical
and skeptical if I see such code. And you asked for it.

Janis

>
> The ``datediff.sh'' script is published in GitHub at: github [dot]
> com/mountaineerbr/scripts
>
> Below is a copy (hopefully formatting is preserved!).
> ###
[ snip 1000+ lines of code ]
> ###
> Cheers!
> JSN

On 11/10/22 21:46, Janis Papanagnou wrote:
> What does the script that AT&T date or GNU date doesn't support in this
> (time-intervals) respect?

I am not sure that `awk' or `date' can be used to calculate time intervals
other than in days, hours, minutes and seconds. So how can you calculate
these time differences with awk? You could get to an _approximate_ result
very easily but it gets more difficult as we need to compensate for a lot
of things, for example not all months have 4 weeks.

> Since I notice some mention of "easter"; which definitions of "easter"
> does it support? (I presume you know that there's not a single one.)
Oh, I just got that Easter script from Dershowitz and Reingold book and
they seem to agree with you about the style of it:

[[ Finally, the computer world is plagued with unintelligible code that seems to work
by magic. Consider the following Unix script for calculating the date of Easter:

echo $* ’[ddsf[lfp[too early
]Pq]s@1583>@
ddd19%1+sg100/1+d3*4/12-sx8*5+25/5-sz5*4/lx-10-sdlg11*20+lz+lx-30%
d[30+]s@0>@d[[1+]s@lg11<@]s@25=@d[1+]s@24=@se44le-d[30+]s@21>@dld+7%-7+
[March ]smd[31-[April ]sm]s@31<@psnlmPpsn1z>p]splpx’ | dc

We want to provide transparent algorithms to replace the gobbledegook that is so
common. ]]

Dc is used only in this function and really I haven't changed it. Also, I am not
sure what you mean by Easter definition?

> Does your script support moon phases? (Something I recently looked for,
> so I am curious.)

The script does not support moon phases. I just checked Dershowitz and Reingold
book and there is even some Lisp code examples. It seems that to find out when
new moon is, you need first calculate moon and sun latitudes, and at least
Venus and Jupiter influence seem worth correcting for... So that is rather
a complex astronomical calculation!

> I don't get it. What's the point in using bash arithmetics and bc (or
> only sometimes)? I mean it wouldn't occur to me that multi-precision
> arithmetic would be necessary for that. For floating point arithmetic,
> OTOH, I'd use ksh (instead of bash) and generally omit bc.

I use bc because you may want to know how many weeks are 10 days? Then
it needs to have decimal precision. I would use Ksh preferably, or Zsh,
however I had to choose one shell and it was bash because I reckon it
is installed in most systems.

> Looks to me like the mentioned date programs or a simple GNU awk date
> implementation supports that already.

I have written some weird scripts that only later did I found out had
their functions already implemented in very well established C programmes.
If that is the case, I would like to know how to do it, because all
datediff shell scripts I have seem can only calculate up to the time unit
of days with precision. But I may be wrong.

> I used inherent TZ support already with dates used in scripts that use
> GNU awk dates and in AT&T or ksh dates. Why do you mention TZ support
> as something special here?
$TZ is mentioned because the script is aware of it even if no date package
is available, thus, it subtracts $TZ from both input dates. $TZ mostly
influences how the processed dates are printed and it is used to find
the UTC time. All calculations are made using UTC times internally.

> You could have avoided unnecessary bash specifics to make your script
> run on other prominent shells (ksh, zsh, or even sh) as well. (Some
> changes are trivial, like local in functions.)

I decided to use all the features of bash to make the script run as fast
as it possibly can. Using test [ instead of [[ makes the script runs
slower, using awk or sed for trivial things are also unnecessary.

> I just skimmed through it and saw some strange constructs and comments;
> e.g. "YYY-..." in a comment named ISO-date, or a $((++RET)) return value
> with undefined and otherwise unused RET variable. (I know it works but
> implementing side effects on undefined global scoped variables that
> will change the return/exit code of a function cal every time, and will
> at times overflow the allowed return value range is not something that
> looks trustworthy to me.)

That is a good point, that variable use is a little weird. I thought to exit
with the code of the same number of failed tests (that is used only in an
isolated function to check if some year is leap or not, so if input is
three years and two of them are not leap years, then the function exits with
2. I thought this may be more useful than exiting with only 1, and yes, it
will overflow with more than 255 increments and may exit with 0.
So this logic is problematic because it is not explained in the help page
and is unstable. In this sense, I will change it to exit with 1 if any
input years is not leap.

> There's a couple places where you use obsolete
> constructs, mix legacy (-eq) and new syntax, or use unnecessary complex
> expressions (e.g. (( (yearA||yearA==0) ... )) in arithmetic context).

These are great observations. I would elaborate on why I used legacy syntax
[[-eq]] but I see your point and will change those instances with ((==)) tests.

Now I only disagree on unnecessary complex testing you pointed out!
In the expression "(( (yearA||yearA==0) ))" I do two tests, the first one
will catch in case input is something not numerical, thus is $yearA is
some weird string, it will fail this test, but there is still the case when
year may be 0000 and thus we also check if that is the case.

I am very interested in simplifying calculations, if you could point out
the unnecessary complexity, I will take a look on that.

> Must have been a pain to write and debug that large piece of code. So
> please don't take my hints and comments too serious. I'm just critical
> and skeptical if I see such code. And you asked for it.

It was a pain to debug it, specially because I am no developer and not very
good with mathematics. But I cannot see how the code could be less robust.

Hope the code can be minimally verified here so I can get more confident.
However, Hroptatyr, who is the developer of C programme `datediff', didn't
say anything bad about my script, in fact he starred it, so IDK.

On Fri, 11 Nov 2022 00:34:37 -0300
castAway <no@where.com> wrote:
> On 11/10/22 21:46, Janis Papanagnou wrote:
> > Since I notice some mention of "easter"; which definitions of "easter"
> > does it support? (I presume you know that there's not a single one.)
> Oh, I just got that Easter script from Dershowitz and Reingold book and
> they seem to agree with you about the style of it:
>
> [[ Finally, the computer world is plagued with unintelligible code that seems to work
> by magic. Consider the following Unix script for calculating the date of Easter:

[...]

> Dc is used only in this function and really I haven't changed it. Also, I am not
> sure what you mean by Easter definition?

Western Easter is generally on a different date than Eastern Orthodox Easter.
For example the ncal man page mentions
-e Display date of easter (for western churches).
[...]
-o Display date of orthodox easter (Greek and Russian Orthodox Churches).

On 11/11/22 07:38, Spiros Bousbouras wrote:
> Western Easter is generally on a different date than Eastern Orthodox Easter.
> For example the ncal man page mentions
> -e Display date of easter (for western churches).
> [...]
> -o Display date of orthodox easter (Greek and Russian Orthodox Churches).

Thanks for that definition. I downloaded ncal from bsdmainutils and checked it.

The unix function from Dershowitz and Reingold book displays Western Church Easter!

I implemented what Papanagnou & Bousbouras suggested and those modifications
are already available at my GitHub. Thanks.

On 11.11.2022 04:34, castAway wrote:
> On 11/10/22 21:46, Janis Papanagnou wrote:
>> What does the script that AT&T date or GNU date doesn't support in this
>> (time-intervals) respect?
>
> I am not sure that `awk' or `date' can be used to calculate time intervals
> other than in days, hours, minutes and seconds. So how can you calculate
> these time differences with awk? You could get to an _approximate_ result
> very easily but it gets more difficult as we need to compensate for a lot
> of things, for example not all months have 4 weeks.

If I'd implement time and date calculations I'd separate the tasks in
three major components; a) transform various external representations
into an internal format, b) do some date and time calculations based
on a tool-chest of basic functions, c) provide output for any desired
external representation. - I understood that in step b you're doing a
difference on dates? - So I'd take the time/date-features that GNU
supports or the native features of tools that already support dates
(date, ksh, etc.), do the transformation, calculation, and output.
(But frankly, I may have misunderstood what your tool actually does.)

>
>> Since I notice some mention of "easter"; which definitions of "easter"
>> does it support? (I presume you know that there's not a single one.)
> Oh, I just got that Easter script from Dershowitz and Reingold book and
> they seem to agree with you about the style of it:
>
> [[ Finally, the computer world is plagued with unintelligible code that
> seems to work
> by magic. Consider the following Unix script for calculating the date of
> Easter:
>
> echo $* ’[ddsf[lfp[too early
> ]Pq]s@1583>@
> ddd19%1+sg100/1+d3*4/12-sx8*5+25/5-sz5*4/lx-10-sdlg11*20+lz+lx-30%
> d[30+]s@0>@d[[1+]s@lg11<@]s@25=@d[1+]s@24=@se44le-d[30+]s@21>@dld+7%-7+
> [March ]smd[31-[April ]sm]s@31<@psnlmPpsn1z>p]splpx’ | dc
>
> We want to provide transparent algorithms to replace the gobbledegook
> that is so
> common. ]]
>
> Dc is used only in this function and really I haven't changed it.

The point was not so much that you took some cryptic code and just
trusted it, it was that if you want to verify that code - in case
of errors or to anticipate any potential errors - you should very
well understand it or be enabled to do so. Neither the cryptic dc
code nor the absence of a comment or [specific] reference supports
that. In other words, the more unclear the construct is the more
inline documentation for support should be present. (Or other more
obvious and comprehensible solutions used.)

> Also, I am not sure what you mean by Easter definition?

Depending on the concrete religion Easter will fall on different
dates (and it's not just a constant offset; it varies from year
to year). I'm not too familiar with the details of any religion
but, e.g., in Greece (orthodox church) Easter is celebrated on a
different date than in Germany (e.g. catholic church).

>
>> Does your script support moon phases? (Something I recently looked for,
>> so I am curious.)
>
> The script does not support moon phases. I just checked Dershowitz and
> Reingold
> book and there is even some Lisp code examples. It seems that to find
> out when
> new moon is, you need first calculate moon and sun latitudes, and at least
> Venus and Jupiter influence seem worth correcting for... So that is rather
> a complex astronomical calculation!

I was recently looking at some code and there's probably similar
cryptic formulas existing. I used an adapted _quantized_ version
(only 8 phases, and a plain integer calculation) for a web page:

function phase_of_the_moon (now) // 0-7, with 0: new, 4: full
{
var diy = day_in_year (now);
var goldn = (now.getFullYear() % 19) + 1;
var epact = (11 * goldn + 18) % 30;
if ((epact == 25 && goldn > 11) || epact == 24)
epact++;
return Math.floor (((((diy + epact) * 6) + 11) % 177) / 22) % 8;
}

Not too complex (but also without comments, so I cannot tell,
to be honest, what's actually going on). I suppose it could be
simplified for an accurate FP representation. (I think to have
seen such a function also on the Net, maybe even on Wikipedia.)

>
>> I don't get it. What's the point in using bash arithmetics and bc (or
>> only sometimes)? I mean it wouldn't occur to me that multi-precision
>> arithmetic would be necessary for that. For floating point arithmetic,
>> OTOH, I'd use ksh (instead of bash) and generally omit bc.
>
> I use bc because you may want to know how many weeks are 10 days? Then
> it needs to have decimal precision. I would use Ksh preferably, or Zsh,
> however I had to choose one shell and it was bash because I reckon it
> is installed in most systems.

Well, I understand your motivation now, but I think that it's not
true, unfortunately. In commercial Unix environments you cannot
rely on the availability of a bash. (That's my experience from
a couple commercial companies I worked for.) Availability of ksh
was different in that respect; I found it everywhere.

But okay, your choice.

>
>> Looks to me like the mentioned date programs or a simple GNU awk date
>> implementation supports that already.
>
> I have written some weird scripts that only later did I found out had
> their functions already implemented in very well established C programmes.
> If that is the case, I would like to know how to do it, because all
> datediff shell scripts I have seem can only calculate up to the time unit
> of days with precision. But I may be wrong.

I'm not sure to understand what you wrote here. Usually it's standard
to support precisions of seconds at least, often milliseconds or even
microseconds or manoseconds. Of course if the shell doesn't support
sub-seconds you have natively only seconds supported. Here are two
examples

$ awk 'BEGIN{a=strftime("%s");
system("sleep 3");
print strftime("%s")-a}'
3

$ ksh -c 'typeset -F a=$(printf "%(%s.%N)T");
sleep 3.14;
typeset -F b=$(printf "%(%s.%N)T");
printf "%f\n" $((b-a))'
3.141979

>
>> I used inherent TZ support already with dates used in scripts that use
>> GNU awk dates and in AT&T or ksh dates. Why do you mention TZ support
>> as something special here?
> $TZ is mentioned because the script is aware of it even if no date package
> is available, thus, it subtracts $TZ from both input dates. $TZ mostly
> influences how the processed dates are printed and it is used to find
> the UTC time. All calculations are made using UTC times internally.
>
>> You could have avoided unnecessary bash specifics to make your script
>> run on other prominent shells (ksh, zsh, or even sh) as well. (Some
>> changes are trivial, like local in functions.)
>
> I decided to use all the features of bash to make the script run as fast
> as it possibly can. Using test [ instead of [[ makes the script runs
> slower, using awk or sed for trivial things are also unnecessary.

If you were going for speed you'd have better avoided bash. :-)

[[...]] is understood by the prominent shells (ksh, zsh); ksh actually
invented that. But I rather mentioned the (unnecessary) 'local' keyword
that other shells not necessarily support (ksh has 'typeset' for that).
But all shells, even Bourne shell support instead of f(){ local i=0 ;}
the standard f()( i=0 )
What I wanted to express is that with a minimum of change you can widen
applicability to more shells.

>
>> I just skimmed through it and saw some strange constructs and comments;
>> e.g. "YYY-..." in a comment named ISO-date, or a $((++RET)) return value
>> with undefined and otherwise unused RET variable. (I know it works but
>> implementing side effects on undefined global scoped variables that
>> will change the return/exit code of a function cal every time, and will
>> at times overflow the allowed return value range is not something that
>> looks trustworthy to me.)
>
> That is a good point, that variable use is a little weird. I thought to
> exit
> with the code of the same number of failed tests (that is used only in an
> isolated function to check if some year is leap or not, so if input is
> three years and two of them are not leap years, then the function exits
> with
> 2. I thought this may be more useful than exiting with only 1, and yes, it
> will overflow with more than 255 increments and may exit with 0.
> So this logic is problematic because it is not explained in the help page
> and is unstable. In this sense, I will change it to exit with 1 if any
> input years is not leap.
>
>> There's a couple places where you use obsolete
>> constructs, mix legacy (-eq) and new syntax, or use unnecessary complex
>> expressions (e.g. (( (yearA||yearA==0) ... )) in arithmetic context).
>
> These are great observations. I would elaborate on why I used legacy syntax
> [[-eq]] but I see your point and will change those instances with ((==))
> tests.
>
> Now I only disagree on unnecessary complex testing you pointed out!
> In the expression "(( (yearA||yearA==0) ))" I do two tests, the first one
> will catch in case input is something not numerical, thus is $yearA is
> some weird string, it will fail this test, but there is still the case when
> year may be 0000 and thus we also check if that is the case.
>
> I am very interested in simplifying calculations, if you could point out
> the unnecessary complexity, I will take a look on that.

On 11.11.2022 17:36, Janis Papanagnou wrote:
> On 11.11.2022 04:34, castAway wrote:
>> On 11/10/22 21:46, Janis Papanagnou wrote:
>>> What does the script that AT&T date or GNU date doesn't support in this
>>> (time-intervals) respect?
>>
>> I am not sure that `awk' or `date' can be used to calculate time intervals
>> other than in days, hours, minutes and seconds. So how can you calculate
>> these time differences with awk? You could get to an _approximate_ result
>> very easily but it gets more difficult as we need to compensate for a lot
>> of things, for example not all months have 4 weeks.
>
> [...]

On re-reading it occurred to me that you were probably not focusing
on the sub-second issue but on support for dates before, say, 1900 or
after 2100, or so. - Yes, Unix tools have different (often restricted)
support for dates outside the Unix Epoch. - So, yes, depending on the
used tool you'd have to transform the external form to an internal
representation that fits this accuracy.

Janis

On 11.11.2022 18:04, Janis Papanagnou wrote:
> On 11.11.2022 17:36, Janis Papanagnou wrote:
>> On 11.11.2022 04:34, castAway wrote:
>>> On 11/10/22 21:46, Janis Papanagnou wrote:
>>>> What does the script that AT&T date or GNU date doesn't support in this
>>>> (time-intervals) respect?
>>>
>>> I am not sure that `awk' or `date' can be used to calculate time intervals
>>> other than in days, hours, minutes and seconds. So how can you calculate
>>> these time differences with awk? You could get to an _approximate_ result
>>> very easily but it gets more difficult as we need to compensate for a lot
>>> of things, for example not all months have 4 weeks.
>>
>> [...]
>
> On re-reading it occurred to me that you were probably not focusing
> on the sub-second issue but on support for dates before, say, 1900 or
> after 2100, or so. - Yes, Unix tools have different (often restricted)
> support for dates outside the Unix Epoch. - So, yes, depending on the
> used tool you'd have to transform the external form to an internal
> representation that fits this accuracy.

And a final remark... - In this case you have to also consider calendar
switches (Julian/Gregorian) in your date calculations. (Not sure your
code supports that.)

Janis

On 11/11/22 13:36, Janis Papanagnou wrote:
> If I'd implement time and date calculations I'd separate the tasks in
> three major components; a) transform various external representations
> into an internal format, b) do some date and time calculations based
> on a tool-chest of basic functions, c) provide output for any desired
> external representation. - I understood that in step b you're doing a
> difference on dates? - So I'd take the time/date-features that GNU
> supports or the native features of tools that already support dates
> (date, ksh, etc.), do the transformation, calculation, and output.
> (But frankly, I may have misunderstood what your tool actually does.)

Thanks for all this advice. I would hear whatever you guys have to say
in comp.unix.shell about style and how to solve coding problems. In step
b, the script counts how many seconds there are between two dates. For that,
it has to loop through all full years (cannot just subtract two dates!).
The remaining full months are also counted one by one. Days that are still
left, can be added to complete one month or a few weeks. Deciding if x days
should add up to a month is tricky as it depends on what month of the year
the first date is.

> The point was not so much that you took some cryptic code and just
> trusted it, it was that if you want to verify that code - in case
> of errors or to anticipate any potential errors - you should very
> well understand it or be enabled to do so. Neither the cryptic dc
> code nor the absence of a comment or [specific] reference supports
> that. In other words, the more unclear the construct is the more
> inline documentation for support should be present. (Or other more
> obvious and comprehensible solutions used.)

That was a good point. This sense of balance between code comment and
code clarity is excellent!

> I was recently looking at some code and there's probably similar
> cryptic formulas existing. I used an adapted _quantized_ version
> (only 8 phases, and a plain integer calculation) for a web page:
>
> function phase_of_the_moon (now) // 0-7, with 0: new, 4: full
> {
> var diy = day_in_year (now);
> var goldn = (now.getFullYear() % 19) + 1;
> var epact = (11 * goldn + 18) % 30;
> if ((epact == 25 && goldn > 11) || epact == 24)
> epact++;
> return Math.floor (((((diy + epact) * 6) + 11) % 177) / 22) % 8;
> }
>

You convinced me that it may be possible to have a moon phase function
that is reasonable to implement within a certain error for the [near]
present time... I *shall* look into this code further and may implement
it at some point! I am not sure about ``a FP representation of it'' yet,
but I will post any follow-ups when I am able to dig into this study..

>>> You could have avoided unnecessary bash specifics to make your script
>>> run on other prominent shells (ksh, zsh, or even sh) as well. (Some
>>> changes are trivial, like local in functions.)

Now that the calculation works, it should not be too hard to implement it
in sh. Maybe if I have got some spare time in the future, that would be
a godo exercise to widen script applicability to other shells, however,
the scripts relies on extended globbing to check and test input...

> As said, I just skimmed through the code because it appears to me too
> overloaded, and I don't want to spend more time on that. The sad fact
> is that when I start I go into every even non-functional detail, say,
> code like
> TIME_ISO8601_FMT='%Y-%m-%dT%H:%M:%S%z'
> ...
> INPUT_FMT="${TIME_ISO8601_FMT:0:17}" #%Y-%m-%dT%H:%M:%S
> where you use a non-standard variable expansion unnecessarily and then
> commenting the actual value.
> Or that you seem to have a lot duplicate code (e.g. there's a leap-year
> function but an explicit leap-year calculation can be found on several
> other places as well.
> (I better stop now.)

Your tidbits on style are quite informative already and I appreciate them.
For this specific example, I reckon it could be written standardly as
INPUT_FMT="${TIME_ISO8601_FMT%??}"
I also see your point on this variable definition not being necessary,
it can indeed be removed and the original variable used instead in this case.

The reason why one can find lots of seemingly duplicate code is either the
code is subtly different and would become more difficult to understand if
these differences were to be set on run time, or simply because of speed
constraints. Millions of dates were tested on my intel i7 and amd processors
and each testing run could take a couple of days.. So the fewest
functions were declared. The leap year checking code is so trivial and easy
to check that is not worth bothering defining a function to it.
Function nesting makes the script run slower.

The organisation point is very important, however the script code is not
a mess as it is, either.

> Based
> on one's own expertise folks have to judge themselves whether it fits
> them.
>
> Janis
>

On 11.11.2022 20:15, castAway wrote:
> On 11/11/22 13:36, Janis Papanagnou wrote:
>
>> I was recently looking at some code and there's probably similar
>> cryptic formulas existing. I used an adapted _quantized_ version
>> (only 8 phases, and a plain integer calculation) for a web page:
>> [moon phase]
>
> You convinced me that it may be possible to have a moon phase function
> that is reasonable to implement within a certain error for the [near]
> present time... I *shall* look into this code further and may implement
> it at some point! I am not sure about ``a FP representation of it'' yet,
> but I will post any follow-ups when I am able to dig into this study..

(Please note that it was *not* a "Request for Feature". Feel free
to ignore it. There's so many things a time/date library could or
should support.)

>
>>>> You could have avoided unnecessary bash specifics to make your script
>>>> run on other prominent shells (ksh, zsh, or even sh) as well. (Some
>>>> changes are trivial, like local in functions.)
>
> Now that the calculation works, it should not be too hard to implement it
> in sh. Maybe if I have got some spare time in the future, that would be
> a godo exercise to widen script applicability to other shells, however,
> the scripts relies on extended globbing to check and test input...

Ksh supports that (ksh globbing, "extended" globbing) as standard
(i.e. without explicitly activating it) and Zsh as well

>
>> [...]
>> TIME_ISO8601_FMT='%Y-%m-%dT%H:%M:%S%z'
>> ...
>> INPUT_FMT="${TIME_ISO8601_FMT:0:17}" #%Y-%m-%dT%H:%M:%S
>> where you use a non-standard variable expansion unnecessarily and then
>> commenting the actual value.
>> Or that you seem to have a lot duplicate code (e.g. there's a leap-year
>> function but an explicit leap-year calculation can be found on several
>> other places as well.
>> (I better stop now.)
>
> Your tidbits on style are quite informative already and I appreciate them.
> For this specific example, I reckon it could be written standardly as
> INPUT_FMT="${TIME_ISO8601_FMT%??}"

My point was rather to omit an unnecessary operation (both substring
expansion or suffix expansion) by, e.g.,
INPUT_FMT="%Y-%m-%dT%H:%M:%S"
TIME_ISO8601_FMT="${INPUT_FMT}%z"
but preferences vary. Also "${TIME_ISO8601_FMT%??}" is misleading for
several reasons (there is not "one format") and might be interpreted,
e.g., as removing the last seconds-formatter; you'd need to inspect
more context. (As said, a matter of preference, style, or experience
what is more or less robust, more or less portable, etc.)

>
> The reason why one can find lots of seemingly duplicate code is either the
> code is subtly different and would become more difficult to understand if

if (( !(year % 4) && ( year % 100 || !(year % 400) ) )) # your leap fun

if (( month == 2 && !(year % 4) && ( year % 100 || !(year % 400) ) ))
if (( month <= 2 && !(year % 4) && ( year % 100 || !(year % 400) ) ))
(( !(y_test % 4) && (y_test % 100 || !(y_test % 400) ) )) && ((++leapcount))
if (( (month_test == 2) && !(yearB % 4) && (yearB % 100 || !(yearB %
400) ) ))
if (( (month_test == 2) && !(yearA % 4) && (yearA % 100 || !(yearA %
400) ) ))

vs.

if (( !(year % 4) && ( year % 100 || !(year % 400) ) )) # your leap fun

if (( month == 2 )) && is_leapyear "${year}"
if (( month <= 2 )) && is_leapyear "${year}"
is_leapyear "${y_test}" && ((++leapcount))
if (( month_test == 2 )) && is_leapyear "${year_B}"
if (( month_test == 2 )) && is_leapyear "${year_A}"

Maintainability aside; are you really saying the code using a function
call is "more difficult to understand"?

And where is the "subtle difference"? - And why is any subtle difference
easier to detect in unstructured copy/past code? - I'll bite!

> these differences were to be set on run time, or simply because of speed
> constraints. Millions of dates were tested on my intel i7 and amd
> processors
> and each testing run could take a couple of days..

The leapyear test code runs on my old legacy system for 1 million tests in
20 seconds (bash, expanded expr)
38 seconds (bash, function call)
3.3 seconds (ksh, expanded expr)
8.0 seconds (ksh, function call)
3 seconds (zsh, expanded expr)
12 seconds (zsh, function call)

> So the fewest
> functions were declared. The leap year checking code is so trivial and easy
> to check that is not worth bothering defining a function to it.
> Function nesting makes the script run slower.

If you have a speed issue, again, I suggest to switch shells for a try.
Bash is slow (see above).

But using a slow shell and then sacrificing maintainability because of
that is even more an issue. YMMV.

In the concrete cases I'd certainly prefer
if is_leapyear "${year}" && optional_other_code
then ...
in the places where you have a duplicated leap-year test expression.

This quality of coding is (at least for me) a criterion to use or ignore
any piece of code. (Or rewrite it.)

>
> The organisation point is very important, however the script code is not
> a mess as it is, either.

No? - If you say so then I take your word for granted. ;-) Have fun!

Janis

On 11/11/2022 23:27, Janis Papanagnou wrote:
> On 11.11.2022 20:15, castAway wrote:
>> On 11/11/22 13:36, Janis Papanagnou wrote:
>>
>>> I was recently looking at some code and there's probably similar
>>> cryptic formulas existing. I used an adapted _quantized_ version
>>> (only 8 phases, and a plain integer calculation) for a web page:
>>> [moon phase]
>>
>> You convinced me that it may be possible to have a moon phase function
>> that is reasonable to implement within a certain error for the [near]
>> present time... I *shall* look into this code further and may implement
>> it at some point! I am not sure about ``a FP representation of it'' yet,
>> but I will post any follow-ups when I am able to dig into this study..
>
> (Please note that it was *not* a "Request for Feature". Feel free
> to ignore it. There's so many things a time/date library could or
> should support.)
>
>>
>>>>> You could have avoided unnecessary bash specifics to make your script
>>>>> run on other prominent shells (ksh, zsh, or even sh) as well. (Some
>>>>> changes are trivial, like local in functions.)
>>
>> Now that the calculation works, it should not be too hard to implement it
>> in sh. Maybe if I have got some spare time in the future, that would be
>> a godo exercise to widen script applicability to other shells, however,
>> the scripts relies on extended globbing to check and test input...
>
> Ksh supports that (ksh globbing, "extended" globbing) as standard
> (i.e. without explicitly activating it) and Zsh as well
>
>>
>>> [...]
>>> TIME_ISO8601_FMT='%Y-%m-%dT%H:%M:%S%z'
>>> ...
>>> INPUT_FMT="${TIME_ISO8601_FMT:0:17}" #%Y-%m-%dT%H:%M:%S
>>> where you use a non-standard variable expansion unnecessarily and then
>>> commenting the actual value.
>>> Or that you seem to have a lot duplicate code (e.g. there's a leap-year
>>> function but an explicit leap-year calculation can be found on several
>>> other places as well.
>>> (I better stop now.)
>>
>> Your tidbits on style are quite informative already and I appreciate them.
>> For this specific example, I reckon it could be written standardly as
>> INPUT_FMT="${TIME_ISO8601_FMT%??}"
>
> My point was rather to omit an unnecessary operation (both substring
> expansion or suffix expansion) by, e.g.,
> INPUT_FMT="%Y-%m-%dT%H:%M:%S"
> TIME_ISO8601_FMT="${INPUT_FMT}%z"
> but preferences vary. Also "${TIME_ISO8601_FMT%??}" is misleading for
> several reasons (there is not "one format") and might be interpreted,
> e.g., as removing the last seconds-formatter; you'd need to inspect
> more context. (As said, a matter of preference, style, or experience
> what is more or less robust, more or less portable, etc.)
>
>>
>> The reason why one can find lots of seemingly duplicate code is either the
>> code is subtly different and would become more difficult to understand if
>
> if (( !(year % 4) && ( year % 100 || !(year % 400) ) )) # your leap fun
>
> if (( month == 2 && !(year % 4) && ( year % 100 || !(year % 400) ) ))
> if (( month <= 2 && !(year % 4) && ( year % 100 || !(year % 400) ) ))
> (( !(y_test % 4) && (y_test % 100 || !(y_test % 400) ) )) && ((++leapcount))
> if (( (month_test == 2) && !(yearB % 4) && (yearB % 100 || !(yearB %
> 400) ) ))
> if (( (month_test == 2) && !(yearA % 4) && (yearA % 100 || !(yearA %
> 400) ) ))
>
> vs.
>
> if (( !(year % 4) && ( year % 100 || !(year % 400) ) )) # your leap fun
>
> if (( month == 2 )) && is_leapyear "${year}"
> if (( month <= 2 )) && is_leapyear "${year}"
> is_leapyear "${y_test}" && ((++leapcount))
> if (( month_test == 2 )) && is_leapyear "${year_B}"
> if (( month_test == 2 )) && is_leapyear "${year_A}"
>
> Maintainability aside; are you really saying the code using a function
> call is "more difficult to understand"?
>
> And where is the "subtle difference"? - And why is any subtle difference
> easier to detect in unstructured copy/past code? - I'll bite!
>
>> these differences were to be set on run time, or simply because of speed
>> constraints. Millions of dates were tested on my intel i7 and amd
>> processors
>> and each testing run could take a couple of days..
>
> The leapyear test code runs on my old legacy system for 1 million tests in
> 20 seconds (bash, expanded expr)
> 38 seconds (bash, function call)
> 3.3 seconds (ksh, expanded expr)
> 8.0 seconds (ksh, function call)
> 3 seconds (zsh, expanded expr)
> 12 seconds (zsh, function call)
>
>> So the fewest
>> functions were declared. The leap year checking code is so trivial and easy
>> to check that is not worth bothering defining a function to it.
>> Function nesting makes the script run slower.
>
> If you have a speed issue, again, I suggest to switch shells for a try.
> Bash is slow (see above).
>
> But using a slow shell and then sacrificing maintainability because of
> that is even more an issue. YMMV.
>
> In the concrete cases I'd certainly prefer
> if is_leapyear "${year}" && optional_other_code
> then ...
> in the places where you have a duplicated leap-year test expression.
>
> This quality of coding is (at least for me) a criterion to use or ignore
> any piece of code. (Or rewrite it.)
>
>>
>> The organisation point is very important, however the script code is not
>> a mess as it is, either.
>
> No? - If you say so then I take your word for granted. ;-) Have fun!
>
> Janis
>

Alternative(ish) to this script; have you looked at dateutils?
http://www.fresse.org/dateutils/

--
Chris Elvidge
England

On Sat, 12 Nov 2022 12:07:15 +0000
Chris Elvidge <chris@mshome.net> wrote:
> On 11/11/2022 23:27, Janis Papanagnou wrote:
> > On 11.11.2022 20:15, castAway wrote:

[...]

> Alternative(ish) to this script; have you looked at dateutils?
> http://www.fresse.org/dateutils/

Assuming "you" is castAway , he mentioned Hroptatyr in his opening post (and
later) and www.fresse.org has "profile for hroptatyr on Stack Exchange" .
So the answer is probably yes.

On 11/10/22 21:46, Janis Papanagnou wrote:
> Looks to me like the mentioned date programs or a simple GNU awk date
> implementation supports that already.

I decided to try and change the script to fit Ksh. More on that later..

Now, I just noticed that `AST date' has got an -E (elapsed) flag:

-E, --elapsed Interpret pairs of arguments as start and stop dates, sum the
differences between all pairs, and list the result as a
fmtelapsed(3) elapsed time on the standard output. If there
are an odd number of arguments then the last time argument is
differenced with the current time.

However, the functionality seems to be very basic:

% $AST/date -E '2002-01-01' '2012-01-01'
9Y11M
% $AST/date -E '12:01:01' '19:02:02'
7h01m
% $AST/date -E '2002-01-01 12:01:01' '2012-01-01 19:01:01'
9Y11M

Now, I know that KSH is very fast and I also read that Ksh code is very convoluted
or very difficult to read and maintain, for example, Mr Siteshwar and Mr Rader
complained a lot of the Ksh code when they were at it trying to develop it further.

So, it comes to me that Mr Korn sacrificed readability and maintainability in
exchange for speed, or am I wrong?

Cheers,
JSN

On 11/11/22 13:36, Janis Papanagnou wrote:
> I was recently looking at some code and there's probably similar
> cryptic formulas existing. I used an adapted _quantized_ version
> (only 8 phases, and a plain integer calculation) for a web page:
>
> function phase_of_the_moon (now) // 0-7, with 0: new, 4: full
> {
> var diy = day_in_year (now);
> var goldn = (now.getFullYear() % 19) + 1;
> var epact = (11 * goldn + 18) % 30;
> if ((epact == 25 && goldn > 11) || epact == 24)
> epact++;
> return Math.floor (((((diy + epact) * 6) + 11) % 177) / 22) % 8;
> }
>
> Not too complex (but also without comments, so I cannot tell,
> to be honest, what's actually going on). I suppose it could be
> simplified for an accurate FP representation. (I think to have
> seen such a function also on the Net, maybe even on Wikipedia.)

What about the following script to get phase of the moon in Ksh?

YEAR_MONTH_DAYS=(31 28 31 30 31 30 31 31 30 31 30 31)
function is_leapyear
{ ((!($1 % 4) && ($1 % 100 || !($1 % 400) ) ))
} function month_maxday
{ typeset month year
month="$1" year="$2"
if ((month==2)) && is_leapyear $year
then echo 29
else echo ${YEAR_MONTH_DAYS[month-1]}
fi
}

#day in the year
function diyf
{ typeset day month year month_test daysum
day="$1" month="$2" year="$3"
for ((month_test=1;month_test<month;++month_test))
do ((daysum+=$(month_maxday "$month_test" "$year")))
done
echo $((day+daysum))
}

#return phase of the moon, use UTC time
function phase_of_the_moon
{ typeset day month year diy goldn epact
day="$1" month="$2" year="$3"

diy=$(diyf "$day" "$month" "$year")
((goldn = (year % 19) + 1))
((epact = (11 * goldn + 18) % 30))
(((epact == 25 && goldn > 11) || epact == 24 )) && ((++epact))

case $(( floor((((((diy + epact) * 6) + 11) % 177) / 22) % 8) )) in
0) echo 'New Moon' ;;
1) echo 'Waxing Crescent' ;;
2) echo 'First Quarter' ;;
3) echo 'Waxing Gibbous' ;;
4) echo 'Full Moon' ;;
5) echo 'Waning Gibbous' ;;
6) echo 'Last Quarter' ;;
7) echo 'Waning Crescent' ;;
esac
}

% phase_of_the_moon 13 11 2022
Waning Gibbous
% phase_of_moon 1 1 1970
Last Quarter

I tentatively checked results against data from
<https://aa.usno.navy.mil/data/MoonPhases>
<http://astropixels.com/ephemeris/phasescat/phases1901.html>
The function prints:
(day, month and year) -> Lunar Phase
"29 12 1969" -> "Waning Gibbous"
"30 12 1969" -> "Last Quarter" [according to usno.navy could still be _Waning Gibbous_]
"31 12 1969" -> "Last Quarter"
However, data from those websites don't match exactly, in the previous example, "Last Quarter" should start only on 31/Dec/2022.
Also:
"24 12 1700" -> "Waxing Gibbous"
"25 12 1700" -> "Full Moon" [according to usno.navy could still be _Waxing Gibbous_]
"26 12 1700" -> "Full Moon"
and:
"25 12 2021" -> "Last Quarter"
"26 12 2021" -> "Last Quarter"
"27 12 2021" -> "Last Quarter" [according to usno.navy _Last Quarter_ should start at this day]
"28 12 2021" -> "Waning Crescent"

Data from these websites have got only 4 lunar phases "New Moon, First Quarter, Full Moon, Last Quarter", while the function returns results within 8 lunar phases, so maybe the reading-frame is a little more relaxed?

I shall do some more research (maybe try and compare some code, there are 777 results from GitHub for "Moon Phase")..

Cheers,
JSN

On 11/12/22 09:07, Chris Elvidge wrote:
> Alternative(ish) to this script; have you looked at dateutils? http://www.fresse.org/dateutils/
>

Yes, I am aware of Dateutils. By the results I got from testing,
the datediff.sh script is just as good as dateutils' datediff programme.
In fact, I found some weird results from Dateutils datediff that I could
not find with datediff.sh. However, Dateutils datediff is much more robust.

On 11/13/22 10:15, castAway wrote:
> On 11/11/22 13:36, Janis Papanagnou wrote:
>> I was recently looking at some code and there's probably similar
>> cryptic formulas existing. I used an adapted _quantized_ version
>> (only 8 phases, and a plain integer calculation) for a web page:
>>
>>    function phase_of_the_moon (now)    // 0-7, with 0: new, 4: full
>>    {
>>      var diy = day_in_year (now);
>>      var goldn = (now.getFullYear() % 19) + 1;
>>      var epact = (11 * goldn + 18) % 30;
>>      if ((epact == 25 && goldn > 11) || epact == 24)
>>          epact++;
>>      return  Math.floor (((((diy + epact) * 6) + 11) % 177) / 22) % 8;
>>    }

Found this function to be from hacklib.c. The original hacklib function
is a little different, as it uses "TM Year" instead of "Year", no floor
rounding and the last mod division is by 7 rather than 8... I tested it,
and Janis' version of the function is more accurate, as far as the few
results I checked are concerned. I don't understand the formula thus IDK
why the hacklib function had to be updated. That being said, it ought to
be a reasonable function to use after I do some more testing!

hacklib.c: <https://nethackwiki.com/wiki/Source:NetHack_1.3d/unixunix.c>

castAway

On 11/11/22 14:06, Janis Papanagnou wrote:
> And a final remark... - In this case you have to also consider calendar
> switches (Julian/Gregorian) in your date calculations. (Not sure your
> code supports that.)

We dont support such difference in calendar because I am not very much
familiar with the difference, we support UNIX time and ISO8601 dates
only, for as far as few centuries as static maths may go.

On 11/11/22 13:36, Janis Papanagnou wrote:

> function phase_of_the_moon (now) // 0-7, with 0: new, 4: full

Bash integer arithmetics do floor rounding by deafults, don't trust,
check it, thus $(( 7/4 )) returns 1... Like Ksh, so maybe the floor rounding
function you mentioned is an overhead... Maybe in Java scripting all integers
are calculated as floating point?

On 11/11/22 13:36, Janis Papanagnou wrote:

> function phase_of_the_moon (now) // 0-7, with 0: new, 4: full

OMG, did you just copy & paste this function ? Well, that seems intuitive,
given references

castAway <no@where.com> writes:
> On 11/11/22 14:06, Janis Papanagnou wrote:
>> And a final remark... - In this case you have to also consider calendar
>> switches (Julian/Gregorian) in your date calculations. (Not sure your
>> code supports that.)
>
> We dont support such difference in calendar because I am not very much
> familiar with the difference, we support UNIX time and ISO8601 dates
> only, for as far as few centuries as static maths may go.

For many purposes, the Proleptic Gregorian Calendar is probably
reasonable, and apparently the ISO 8601 standard explicitly requires it.
It extends the Gregorian leap-year rules into the past, before its
actual introduction. It avoids a discontinuity, but dates in the far
past will differ from what they would have been called at the time.

The transition from Julian to Gregorian happened at different times in
different places, from 1582 up to the early 20th century.

https://en.wikipedia.org/wiki/Proleptic_Gregorian_calendar
https://en.wikipedia.org/wiki/List_of_adoption_dates_of_the_Gregorian_calendar_by_country

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for XCOM Labs
void Void(void) { Void(); } /* The recursive call of the void */

castAway <no@where.com> writes:

> On 11/11/22 13:36, Janis Papanagnou wrote:
>
>> function phase_of_the_moon (now) // 0-7, with 0: new, 4: full
>
> Bash integer arithmetics do floor rounding by deafults,

No. Bash's integer division truncates towards zero. The manual says
the results as "as in C", which presumably means modern C. In C90, x/y
with either operand negative was implementation defined. Since C99 the
result is truncated towards zero.

--
Ben.

On 16.11.2022 02:14, castAway wrote:
> On 11/11/22 13:36, Janis Papanagnou wrote:
>
>> function phase_of_the_moon (now) // 0-7, with 0: new, 4: full
>
> Bash integer arithmetics do floor rounding by deafults, don't trust,

Sorry if not having been clear here; where I wrote "for a web page"
I indicated - if not already deducible by the syntax - that this is
Javascript code (not bash, not C, etc.)

function phase_of_the_moon (now) // 0-7, with 0: new, 4: full
{
var diy = day_in_year (now);
var goldn = (now.getFullYear() % 19) + 1;
var epact = (11 * goldn + 18) % 30;
if ((epact == 25 && goldn > 11) || epact == 24)
epact++;
return Math.floor (((((diy + epact) * 6) + 11) % 177) / 22) % 8;
}

> check it, thus $(( 7/4 )) returns 1... Like Ksh,

Note that Ksh does arithmetic in a context sensitive way; 7/4 is
integer arithmetic (and behaves as you say, while 7./4 or 7/4. or
7./4. or 7.0/4.0 does FP arithmetic (with result 1.75).

I haven't implemented or needed that moon-phase code in shell.

> so maybe the floor rounding
> function you mentioned is an overhead... Maybe in Java scripting all
> integers are calculated as floating point?

Don't ask me! - Javascript as language has many design flaws.
The reason I use it occasionally is to support dynamic web
content, and since I have no own webserver running to do that
processing server-side I use this simple client-side option.
Every time I use it (after longer breaks) I have to re-think
about Javascript's quirks. I seem to recall that the origin
of the algorithm was programmed in C with integer arithmetic
and the Math.floor() had been identified as necessary when I
transcribed it.

Janis

On 16.11.2022 02:37, castAway wrote:
> On 11/11/22 13:36, Janis Papanagnou wrote:
>
>> function phase_of_the_moon (now) // 0-7, with 0: new, 4: full
>
> OMG, did you just copy & paste this function ? Well, that seems intuitive,
> given references

Not copy/past but a straightforward transcription. Note that this is
not production code or code I published for others, so I don't need
references for my own use. But if you are interested I can provide
the comment from the C source code for you - here it is... (HTH)

/*
* moon period = 29.53058 days ~= 30, year = 365.2422 days
* days moon phase advances on first day of year compared to preceding year
* = 365.2422 - 12*29.53058 ~= 11
* years in Metonic cycle (time until same phases fall on the same days of
* the month) = 18.6 ~= 19
* moon phase on first day of year (epact) ~= (11*(year%19) + 29) % 30
* (29 as initial condition)
* current phase in days = first day phase + days elapsed in year
* 6 moons ~= 177 days
* 177 ~= 8 reported phases * 22
* + 11/22 for rounding
*/

As also said already, I also seem to recall that I had also found some
description in Wikipedia; if I recall that correctly you'll certainly
find it without my assistance.

Janis

On 12.11.2022 16:40, castAway wrote:
> On 11/10/22 21:46, Janis Papanagnou wrote:
>> Looks to me like the mentioned date programs or a simple GNU awk date
>> implementation supports that already.
>
> [...]
>
> Now, I know that KSH is very fast and I also read that Ksh code is very
> convoluted
> or very difficult to read and maintain, for example, Mr Siteshwar and Mr
> Rader
> complained a lot of the Ksh code when they were at it trying to develop
> it further.
>
> So, it comes to me that Mr Korn sacrificed readability and
> maintainability in
> exchange for speed, or am I wrong?

I can just speculate here; my impression is that they implemented so
many new and non-trivial concepts (in addition to the optimizations)
that at some point they maybe neglected to maintain code quality as
first and IMO most important goal.

That's why I'd suggest to use the version "ks93 u+m" that Martijn
Dekker maintains; it is announced here in this newsgroup and fixed a
lot of bugs in addition to some modifications.

HTH.

Janis

>
> Cheers,
> JSN

On 13.11.2022 21:23, castAway wrote:
> On 11/13/22 10:15, castAway wrote:
>> On 11/11/22 13:36, Janis Papanagnou wrote:
>>> I was recently looking at some code and there's probably similar
>>> cryptic formulas existing. I used an adapted _quantized_ version
>>> (only 8 phases, and a plain integer calculation) for a web page:
>>>
>>> function phase_of_the_moon (now) // 0-7, with 0: new, 4: full
>>> {
>>> var diy = day_in_year (now);
>>> var goldn = (now.getFullYear() % 19) + 1;
>>> var epact = (11 * goldn + 18) % 30;
>>> if ((epact == 25 && goldn > 11) || epact == 24)
>>> epact++;
>>> return Math.floor (((((diy + epact) * 6) + 11) % 177) / 22) % 8;
>>> }
>
> Found this function to be from hacklib.c.

Oh, you found exactly the same source package that I also used. :-)
(Mine is from a more contemporary version of Nethack, though, but this
part has obviously not changed since Nethack version 1.3.)

> The original hacklib function
> is a little different, as it uses "TM Year" instead of "Year", no floor
> rounding and the last mod division is by 7 rather than 8... I tested it,

No. The C source function is doing the last step as _binary_ operation
... & 7
which is equivalent here to the _arithmetic_ counterpart
... % 8
that uses the modulo operator (as opposed to bit-wise 'and').

Note that the hacklib.c code is _very old_ (probably many decades; I'm
too lazy to check the exact date), so a speculation is that the bit-wise
'and' was considered a speed optimization (over modulo) at these times.

Janis

> and Janis' version of the function is more accurate, as far as the few
> results I checked are concerned. I don't understand the formula thus IDK
> why the hacklib function had to be updated. That being said, it ought to
> be a reasonable function to use after I do some more testing!
>
> hacklib.c: <https://nethackwiki.com/wiki/Source:NetHack_1.3d/unixunix.c>
>
> castAway
>