Just sharing what I've learned, hope some of you can adapt
it for your own use.

Calculates the name of the weekday (Sun, Mon, etc) for the
1st day of a given month & year...

https://busybox.neocities.org/notes/get-first-day-of-month.txt

--
:wq
Mike Sanders

In article <urrj5l$124o9$1@dont-email.me>,
Mike Sanders <porkchop@invalid.foo> wrote:
>Just sharing what I've learned, hope some of you can adapt
>it for your own use.
>
>Calculates the name of the weekday (Sun, Mon, etc) for the
>1st day of a given month & year...
>
>https://busybox.neocities.org/notes/get-first-day-of-month.txt

Here's the guts of my version of the Zeller algorithm:

int day(d,m,y)
int d, m, y;
{ if (m < 3) {
m += 12;
y--;
}
return (d + (13*m-27)/5 + y + y/4 - y/100 + y/400) % 7;
}

I assume the two versions end up being equivalent.

BTW, how long do you think it will be until this thread gets hijacked into
a long, acrimonious debate about what the definition of the first day of
the month is and how various cultures define it differently, and how
insensitive we are (especially, if "we" are USA Americans) to assume that
our way is the only way? A matter of hours, I suspect.

--
You know politics has really been turned upside down when you have someone in the
government with a last name of Cheney (Liz, Senator from Wyoming) who is the voice of
reason.

On 01.03.2024 16:39, Kenny McCormack wrote:
> In article <urrj5l$124o9$1@dont-email.me>,
> Mike Sanders <porkchop@invalid.foo> wrote:
>> Just sharing what I've learned, hope some of you can adapt
>> it for your own use.
>>
>> Calculates the name of the weekday (Sun, Mon, etc) for the
>> 1st day of a given month & year...
>>
>> https://busybox.neocities.org/notes/get-first-day-of-month.txt
>
> Here's the guts of my version of the Zeller algorithm:
>
> int day(d,m,y)
> int d, m, y;
> {
> if (m < 3) {
> m += 12;
> y--;
> }
> return (d + (13*m-27)/5 + y + y/4 - y/100 + y/400) % 7;
> }
>
> I assume the two versions end up being equivalent.

Are they?

I'm certainly irritated about the OP's final

return (f % 7) - 1;

returning values from -1 to 5. And then using these indexes
to address a C array. (Looks wrong to me, but I'm anyway
not interested in second hand copies of generally available
algorithms; there's little value.)

Janis

Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:
[...]
>> In article <urrj5l$124o9$1@dont-email.me>,
>> Mike Sanders <porkchop@invalid.foo> wrote:
>>> Just sharing what I've learned, hope some of you can adapt
>>> it for your own use.
>>>
>>> Calculates the name of the weekday (Sun, Mon, etc) for the
>>> 1st day of a given month & year...
>>>
>>> https://busybox.neocities.org/notes/get-first-day-of-month.txt
[...]
> I'm certainly irritated about the OP's final
>
> return (f % 7) - 1;
>
> returning values from -1 to 5. And then using these indexes
> to address a C array. (Looks wrong to me, but I'm anyway
> not interested in second hand copies of generally available
> algorithms; there's little value.)

Yes, that's a bug in the original code. The program only tests for
August 2024, but the algorithm fails for June 2024, which starts on
Saturday.

One fix is to change
return (f % 7) - 1;
to:
return (f + 6) % 7;
which works correctly at least for all months of 2024.

Negative index values can be valid. For example, foo[-1] can be valid,
but only if foo is a pointer to an array element other than the first
one, not if foo is an array object.

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

On 01.03.2024 17:28, Keith Thompson wrote:
> Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:
> [...]
>>> In article <urrj5l$124o9$1@dont-email.me>,
>>> Mike Sanders <porkchop@invalid.foo> wrote:
>>>> Just sharing what I've learned, hope some of you can adapt
>>>> it for your own use.
>>>>
>>>> Calculates the name of the weekday (Sun, Mon, etc) for the
>>>> 1st day of a given month & year...
>>>>
>>>> https://busybox.neocities.org/notes/get-first-day-of-month.txt
> [...]
>> I'm certainly irritated about the OP's final
>>
>> return (f % 7) - 1;
>>
>> returning values from -1 to 5. And then using these indexes
>> to address a C array. (Looks wrong to me, but I'm anyway
>> not interested in second hand copies of generally available
>> algorithms; there's little value.)
>
> Yes, that's a bug in the original code. The program only tests for
> August 2024, but the algorithm fails for June 2024, which starts on
> Saturday.
>
> One fix is to change
> return (f % 7) - 1;
> to:
> return (f + 6) % 7;
> which works correctly at least for all months of 2024.

Yes. Though I'd have done the correction on the previous line.

int f = d + ... - 1;
return f % 7;

To me that would be clearer.

Janis

On 01.03.2024 17:33, Janis Papanagnou wrote:
>
> Yes. Though I'd have done the correction on the previous line.
>
> int f = d + ... - 1;
> return f % 7;
>
> To me that would be clearer.

Or completely removing the 'd' and the '-1' since 'd' is actually
a (non-const declared) constant and equals to 1.

(Gee! Why do I mind, anyway.)

>
> Janis
>

gazelle@shell.xmission.com (Kenny McCormack) writes:
>In article <urrj5l$124o9$1@dont-email.me>,
>Mike Sanders <porkchop@invalid.foo> wrote:
>>Just sharing what I've learned, hope some of you can adapt
>>it for your own use.
>>
>>Calculates the name of the weekday (Sun, Mon, etc) for the
>>1st day of a given month & year...
>>
>>https://busybox.neocities.org/notes/get-first-day-of-month.txt
>
>Here's the guts of my version of the Zeller algorithm:
>
>int day(d,m,y)
>int d, m, y;
>{
> if (m < 3) {
> m += 12;
> y--;
> }
> return (d + (13*m-27)/5 + y + y/4 - y/100 + y/400) % 7;
>}
>
>I assume the two versions end up being equivalent.
>
>BTW, how long do you think it will be until this thread gets hijacked into
>a long, acrimonious debate about what the definition of the first day of
>the month is and how various cultures define it differently, and how
>insensitive we are (especially, if "we" are USA Americans) to assume that
>our way is the only way? A matter of hours, I suspect.

Seconds, it would appear, as you have highjacked your own thread.

On 01.03.2024 16:39, Kenny McCormack wrote:
>
> Here's the guts of my version of the Zeller algorithm:
>
> int day(d,m,y)
> int d, m, y;
> {
> if (m < 3) {
> m += 12;
> y--;
> }
> return (d + (13*m-27)/5 + y + y/4 - y/100 + y/400) % 7;
> }

I'm wondering what would be the better approach, using some date
functions or calculating it by a formula. (Serious question.)

I'm asking since I had previously used time-functions in another
context (determining Fri 13th dates) for such a purpose. And the
rewrite to the "first day" task is simple, and the code pattern
very flexible. Here's the Gawk counterpart just for illustration:

BEGIN { y = ARGV[1] ; m = ARGV[2]
print strftime ("%a", mktime (y " " m " 1 0 0 0"))
}

....and I'm sure you can also use this approach in C.

So what's more advantageous? - Is the domain of one or the other
approach restricted? Is one or the other more accurate? Or may
the runtime be an issue?

Janis

Kenny McCormack <gazelle@shell.xmission.com> wrote:

> Here's the guts of my version of the Zeller algorithm:
>
> int day(d,m,y)
> int d, m, y;
> {
> if (m < 3) {
> m += 12;
> y--;
> }
> return (d + (13*m-27)/5 + y + y/4 - y/100 + y/400) % 7;
> }
>
> I assume the two versions end up being equivalent.

Hey-hey Kenny!

Many thanks for sharing this, now I have something to compare it too
more thoroughly.
> BTW, how long do you think it will be until this thread gets hijacked into
> a long, acrimonious debate about what the definition of the first day of
> the month is and how various cultures define it differently, and how
> insensitive we are (especially, if "we" are USA Americans) to assume that
> our way is the only way? A matter of hours, I suspect.

Well...

--
:wq
Mike Sanders

Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:

> Yes, that's a bug in the original code. The program only tests for
> August 2024, but the algorithm fails for June 2024, which starts on
> Saturday.
>
> One fix is to change
> return (f % 7) - 1;
> to:
> return (f + 6) % 7;
> which works correctly at least for all months of 2024.
>
> Negative index values can be valid. For example, foo[-1] can be valid,
> but only if foo is a pointer to an array element other than the first
> one, not if foo is an array object.

Thanks Keith, will use this moving forward. Glad to have some extra
eyeballs on it.

--
:wq
Mike Sanders

Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:
> On 01.03.2024 17:33, Janis Papanagnou wrote:
>> Yes. Though I'd have done the correction on the previous line.
>>
>> int f = d + ... - 1;
>> return f % 7;
>>
>> To me that would be clearer.
>
> Or completely removing the 'd' and the '-1' since 'd' is actually
> a (non-const declared) constant and equals to 1.
>
> (Gee! Why do I mind, anyway.)

I think the point of defining 'd' is to allow for computing the day of
the week for days of the month other than the first. The code as
presented suggests a lot of opportunities for generalization (such as
handling months other than August 2024). The local variable 'd' could
be replaced by a parameter 'int mday'.

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

Kenny McCormack <gazelle@shell.xmission.com> wrote:

> Here's the guts of my version of the Zeller algorithm:
>
> int day(d,m,y)
> int d, m, y;
> {
> if (m < 3) {
> m += 12;
> y--;
> }
> return (d + (13*m-27)/5 + y + y/4 - y/100 + y/400) % 7;
> }

I've put this right to work too Kenny...

Prints calander for the given year with every 2 months adjacent

https://busybox.neocities.org/notes/adjacent-calendars.txt

Example...

Jan Feb
Sun Mon Tue Wed Thu Fri Sat Sun Mon Tue Wed Thu Fri Sat
1 1 2 3 4 5
2 3 4 5 6 7 8 6 7 8 9 10 11 12
9 10 11 12 13 14 15 13 14 15 16 17 18 19
16 17 18 19 20 21 22 20 21 22 23 24 25 26
23 24 25 26 27 28 29 27 28
30 31

--
:wq
Mike Sanders

On 01.03.2024 19:34, Keith Thompson wrote:
> Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:
>> On 01.03.2024 17:33, Janis Papanagnou wrote:
>>> Yes. Though I'd have done the correction on the previous line.
>>>
>>> int f = d + ... - 1;
>>> return f % 7;
>>>
>>> To me that would be clearer.
>>
>> Or completely removing the 'd' and the '-1' since 'd' is actually
>> a (non-const declared) constant and equals to 1.
>>
>> (Gee! Why do I mind, anyway.)
>
> I think the point of defining 'd' is to allow for computing the day of
> the week for days of the month other than the first. The code as
> presented suggests a lot of opportunities for generalization (such as
> handling months other than August 2024). The local variable 'd' could
> be replaced by a parameter 'int mday'.

Surely I am aware of that. But the OP's code isn't addressing any
generalization (cf. "int getFirstDayOfMonth(int year, int month)").
If you'd strive for a generalization you'd define a function like
the one Kenny posted (cf. "int day(d,m,y)"). If you want a special
function (for whatever reason) as the OP did you can as well just
optimize it by reducing redundant parts. (Anyway, it's not worth
the dispute.)

Janis

porkchop@invalid.foo (Mike Sanders) writes:
>Kenny McCormack <gazelle@shell.xmission.com> wrote:
>
>> Here's the guts of my version of the Zeller algorithm:
>>
>> int day(d,m,y)
>> int d, m, y;
>> {
>> if (m < 3) {
>> m += 12;
>> y--;
>> }
>> return (d + (13*m-27)/5 + y + y/4 - y/100 + y/400) % 7;
>> }
>
>I've put this right to work too Kenny...
>
>Prints calander for the given year with every 2 months adjacent
>
>https://busybox.neocities.org/notes/adjacent-calendars.txt
>
>Example...
>
> Jan Feb
> Sun Mon Tue Wed Thu Fri Sat Sun Mon Tue Wed Thu Fri Sat
> 1 1 2 3 4 5
> 2 3 4 5 6 7 8 6 7 8 9 10 11 12
> 9 10 11 12 13 14 15 13 14 15 16 17 18 19
> 16 17 18 19 20 21 22 20 21 22 23 24 25 26
> 23 24 25 26 27 28 29 27 28
> 30 31

That must not have been for 2024, or you have a bug.

A calendar utility comes with most linux systems. It also supports
ISO 8601 which starts the week on Monday instead of Sunday.

https://en.wikipedia.org/wiki/ISO_8601

https://github.com/util-linux/util-linux/blob/master/misc-utils/cal.c

$ cal 2024
2024

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

Scott Lurndal <scott@slp53.sl.home> wrote:

> That must not have been for 2024, or you have a bug.

Well Scott, in the code of the link posted its displaying 2022:

int year = 2022;
> A calendar utility comes with most linux systems. It also supports
> ISO 8601 which starts the week on Monday instead of Sunday.

Yes sir, I know that. But I want to build my own instead so I can
learn more about it. Even if that means reiventing the wheel, at
least I'll learn it as I wish. Hoping not to sound contrite,
cant we all just help each other learn? Darn man.

--
:wq
Mike Sanders

Scott Lurndal <scott@slp53.sl.home> wrote:

> https://en.wikipedia.org/wiki/ISO_8601

Have partial ISO8601 compliance now (when using option: -D=2):

Usage: DATES [-OPTIONS] FILE1 [FILE2 ...]

-A=NUM Number of days in advance to look ahead (366 max)
-P=NUM Number of days in the past to look back (366 max)
-D=NUM Format dates as: 1 mm/dd/yyyy, 2 yyyy/mm/dd
-S=NUM Separate date fields using: 1 Slash, 2 Dash, 3 Dot
-X=NUM Export results as: 1 TXT, 2 CSV, 3 SQL, 4 HTML
-T=TAG Filter results for 'TAG' (16 characters max)
-H Include holidays (see manual for list)
-W Include weekday abbreviations
-F Include attribute flags (see manual for details)
-C Display calendar for current year
-M Display embedded user manual

Error levels returned:

3 Option syntax errors
2 File open-read errors
1 Dates match today or matching tags
0 No dates match today or no tags match

But hey its Friday I should lighten up & have some fun:

#include <stdio.h>
#include <stdlib.h>
#include <time.h>

const char *getChineseZodiac(int year) {

const char* animals[] = {
"Rat", "Ox", "Tiger", "Rabbit", "Dragon", "Snake",
"Horse", "Goat", "Monkey", "Rooster", "Dog", "Pig"
};

return animals[year % 12];
}

int main() {

time_t now = time(NULL);
struct tm *localTime = localtime(&now);
int year = localTime->tm_year;
printf("%d Year of the %s\n", year + 1900, getChineseZodiac(year));

return 0;
}

--
:wq
Mike Sanders

Kenny McCormack ha scritto:
> In article <urrj5l$124o9$1@dont-email.me>,
> Mike Sanders <porkchop@invalid.foo> wrote:
>> Just sharing what I've learned, hope some of you can adapt
>> it for your own use.
>>
>> Calculates the name of the weekday (Sun, Mon, etc) for the
>> 1st day of a given month & year...
>>
>> https://busybox.neocities.org/notes/get-first-day-of-month.txt
>
> Here's the guts of my version of the Zeller algorithm:
>
> int day(d,m,y)
> int d, m, y;
> {
> if (m < 3) {
> m += 12;
> y--;
> }
> return (d + (13*m-27)/5 + y + y/4 - y/100 + y/400) % 7;

Hi,
I am referring in particular to this part of the equation:
y + y/4 - y/100 + y/400
Shouldn't it be calculated in a floating point and then truncated only
the final result? Because, for example, if the year is 2024, the
floating point calculation is 2514 (2514.82) while executed between
integer is 2515.

> }
>
> I assume the two versions end up being equivalent.
>
> BTW, how long do you think it will be until this thread gets hijacked into
> a long, acrimonious debate about what the definition of the first day of
> the month is and how various cultures define it differently, and how
> insensitive we are (especially, if "we" are USA Americans) to assume that
> our way is the only way? A matter of hours, I suspect.
>

On 2024-03-01, Kenny McCormack <gazelle@shell.xmission.com> wrote:
> int day(d,m,y)
> int d, m, y;
> {
[...]
> BTW, how long do you think it will be until this thread gets hijacked into
> a long, acrimonious debate about what the definition of the first day of
> the month is and how various cultures define it differently, and how

Pissing on new code using old-style C in 5... 4... 3....

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

porkchop@invalid.foo (Mike Sanders) writes:
>Scott Lurndal <scott@slp53.sl.home> wrote:
>
>> https://en.wikipedia.org/wiki/ISO_8601
>
>Have partial ISO8601 compliance now (when using option: -D=2):

Nice.

>
>Usage: DATES [-OPTIONS] FILE1 [FILE2 ...]
>
>-A=NUM Number of days in advance to look ahead (366 max)
>-P=NUM Number of days in the past to look back (366 max)
>-D=NUM Format dates as: 1 mm/dd/yyyy, 2 yyyy/mm/dd
>-S=NUM Separate date fields using: 1 Slash, 2 Dash, 3 Dot
>-X=NUM Export results as: 1 TXT, 2 CSV, 3 SQL, 4 HTML
>-T=TAG Filter results for 'TAG' (16 characters max)
>-H Include holidays (see manual for list)
>-W Include weekday abbreviations
>-F Include attribute flags (see manual for details)
>-C Display calendar for current year
>-M Display embedded user manual
>

If I may suggest:

https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap12.html

'-h' or '-?' have traditionally been used to display
usage information for an utility.

>Error levels returned:
>
>3 Option syntax errors
>2 File open-read errors
>1 Dates match today or matching tags
>0 No dates match today or no tags match

For commands defined by POSIX (and generally in
unix), an exit status of zero indicates success.

On 02.03.2024 15:46, Scott Lurndal wrote:
> porkchop@invalid.foo (Mike Sanders) writes:
>>
>> Usage: DATES [-OPTIONS] FILE1 [FILE2 ...]
>>[...]
>
> If I may suggest:
>
> https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap12.html
>
> '-h' or '-?' have traditionally been used to display
> usage information for an utility.

Or, since there's a mandatory file name argument, provide usage
information (also) if no argument or option is provided.

Janis

> [...]

Scott Lurndal <scott@slp53.sl.home> wrote:

> If I may suggest:
>
> https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap12.html
>
> '-h' or '-?' have traditionally been used to display
> usage information for an utility.

Yep, it will definitely be '-?' (still working to finalize things).

Many thanks for the link too btw.
>>Error levels returned:
>>
>>3 Option syntax errors
>>2 File open-read errors
>>1 Dates match today or matching tags
>>0 No dates match today or no tags match
>
> For commands defined by POSIX (and generally in
> unix), an exit status of zero indicates success.

Oh yeah. Have been wrestling with the potential
consequences of this for a good while. I think I'm
going leave it as is because, (only speaking for
myself here) the POSIX 0 good, 1 bad is terrible.
This is perhaps the only area I've ever seen where
other OSs, like Windows, have a superior methodology
on the issue. 0/1 provides next to no nuance. But
I'm no expert, just my experience.

Thanks again for the links Scott, I'll read them this
weekend.

--
:wq
Mike Sanders

On 02.03.2024 20:59, Mike Sanders wrote:
>
> Oh yeah. Have been wrestling with the potential
> consequences of this for a good while. I think I'm
> going leave it as is because, (only speaking for
> myself here) the POSIX 0 good, 1 bad is terrible.

Again you have a misconception; errors on Unix systems are
regularly indicated by any value unequal to 0, not only by 1.
That way you can differentiate any possible errors or types
of errors.

> This is perhaps the only area I've ever seen where
> other OSs, like Windows, have a superior methodology
> on the issue.

(I would be astonished. But since you haven't provided any
hint on its specific "methodology" the statement is void.)

> 0/1 provides next to no nuance.

That's why on Unixes you can and typically return more than
just two values.

> But I'm no expert, just my experience.

You haven't provided any evidence or facts of experience.

Janis

porkchop@invalid.foo (Mike Sanders) writes:
> Scott Lurndal <scott@slp53.sl.home> wrote:
>> If I may suggest:
>>
>> https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap12.html
>>
>> '-h' or '-?' have traditionally been used to display
>> usage information for an utility.
>
> Yep, it will definitely be '-?' (still working to finalize things).

I wouldn't use '-?'. The '?' character is a wildcard in most Unix
shells. If you happen to have a file in the current directory that
matches the pattern, it will expand to the name of that file. If you
don't, the behavior depends on the shell and settings.

$ ls -l
total 0
-rw-r--r-- 1 kst kst 0 Mar 2 14:14 -h
$ /bin/echo -?
-h
$

And most users of Unix-like systems won't expect '-?' to be an option;
'-h' is much more common.

> Many thanks for the link too btw.
>
>>>Error levels returned:
>>>
>>>3 Option syntax errors
>>>2 File open-read errors
>>>1 Dates match today or matching tags
>>>0 No dates match today or no tags match
>>
>> For commands defined by POSIX (and generally in
>> unix), an exit status of zero indicates success.
>
> Oh yeah. Have been wrestling with the potential
> consequences of this for a good while. I think I'm
> going leave it as is because, (only speaking for
> myself here) the POSIX 0 good, 1 bad is terrible.
> This is perhaps the only area I've ever seen where
> other OSs, like Windows, have a superior methodology
> on the issue. 0/1 provides next to no nuance. But
> I'm no expert, just my experience.

The C standard, not just POSIX, defines 0 as a successful status. If
your program is intended to work on Unix-like systems (or on Windows if
I'm not mistaken), using a status of 0 to indicate an error will cause
problems. Conventions exist for a reason.

Use 0 for success, 1 for unspecified errors, and other positive values
for more specific errors.

> Thanks again for the links Scott, I'll read them this
> weekend.

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

On 3/2/24 14:59, Mike Sanders wrote:
....
> going leave it as is because, (only speaking for
> myself here) the POSIX 0 good, 1 bad is terrible.

It would be, if that's what POSIX required. Instead, it uses 0 - good,
non-zero bad. Note that 0 representing successful results is mandated by
the C standard as well. EXIT_SUCCESS is another way of indicating
success, which might or might not be the same as 0. EXIT_FAILURE is the
only portable way to indicate failure as far as C itself is concerned,
but if you're willing to write POSIX-specific code, you can use a much
wider variety of values. The same is true of all of the other operating
systems I've written C code for (Windows and VMS, mostly).

> This is perhaps the only area I've ever seen where
> other OSs, like Windows, have a superior methodology
> on the issue. 0/1 provides next to no nuance.

The lack of nuance is apparently the result of your being unaware of the
fact that 1 is not the only permitted error return.

Keep in mind that the make utility and shells designed for Unix-like
systems (as well as many other programs targeting such systems) expect 0
for success, and may produce unexpected results if you violate that
convention.

Scott Lurndal wrote:
> porkchop@invalid.foo (Mike Sanders) writes:
>> Error levels returned:
>>
>> 3 Option syntax errors
>> 2 File open-read errors
>> 1 Dates match today or matching tags
>> 0 No dates match today or no tags match
>
> For commands defined by POSIX (and generally in
> unix), an exit status of zero indicates success.

Also on Windows, an exit status of zero indicates success and non-zero
failure. From a command prompt, the status of the last command can be
accessed via the %ERRORLEVEL% environment variable (similar to $? on *nix).

--
Mark.