Becuase the dayOfWk( function on the calculator isn't correct, I decided to try to make a program that calculates the day of week correctly.
For that I searched on internet for a formula that can be used to calculate it, and I came upon the Zeller's congruence.
I have already tested the formula and it seems to be working.

I still have to make it possible to set when your specific country changed to the Gregorian calendar, and maybe I'll make a option to set the date notation (YYYY/MM/DD - DD/MM/YYYY.......) but every time I tried that before, I got my program not working anymore...
Can that happen if you use too much Goto commands?
I've read that it can cause memory leak or something like that, but can that cause your program to quit when it shouldn't?
Becuase that's what's happening when I try to add the option to set a different date notation...

If I can't add that option, what date notation should I then use?
YYYY/MM/DD, DD/MM/YYYY, MM/DD/YYYY, etc...

I've here some screenshot's of the parts of the program that are already ready:

Wait, how is the dayOfWk() command incorrect? Is it because the output range is 1-7 and not 0-6?

No that isn't it.
If you try dates below 1582 the outcome will be worse the lower you get.(not always, but mostly..)
I tested it with a friend of mine and we came to the conclusion that even calculating the output of the command to the outcome for the Julian calendar doesn't give the correct day.

We didn't really test with dates after 1600, but from what we tried there, I think that that dates are correct with dayOfWk(.
But much lower it's just incorrect.

I've now added all parts of the code together and tried if it still worked, but something is wrong and I haven't found yet what.
Well, I know where I should probably search, because I know where it goes wrong....
So I've some search work to do...

I'm not sure what exactly you mean by that, but if you're saying that its output doesn't match the Julian calendar, that's because it's not programmed with the Julian calendar, period. As other people have been pointing out in chat, Western nations have, over the past few centuries, been switching from the Julian calendar to Gregorian calendar. As a result, calculating anything involving dates before 1919 requires knowing what calendar was in use at the time for the country the date was written in---Russia didn't switch until 1918! Scholars need a comprehensive database when converting dates.

The calculator certainly isn't programmed with such a database, and the syntax for the dayOfWk() command doesn't have an argument for that. The calculator will always assume the argument is the Gregorian calendar, which repeats every four hundred years. If you want to research and write your own date conversion program, have fun, but don't blame the calculator for this; I believe even Windows, Android, iOS, and every other modern operating system has the same limitation.

To solve that problem I let the user input when the calendar did change.
That's also usable if they want to calculate the day of week of a date in another area.

So you're saying that if the Greg. calendar repeats every 400 years, does that mean there would be instances like 2 Thursdays in a row? Or something like Sunday then Wednesday?

Why would you think that? There are 365*400+97=146097 days in 400 years, which is divisible by 7.

I've finally found the bugs that I had!
Actually it were all stupid bugs...
I used:

Code:

Using 'or' instead of 'and'.....
And I had some pieces of code outside a If statement which meant that it was never executed when it should.....

But now the ICE version is ready, so I'll now only need to make a BASIC version, which is what most of you voted on.

I've made the TI-BASIC version and uploaded both version to the archives.

I've here the links:
The ICE version :
http://ceme.tech/DL2051

The TI-BASIC version:
http://ceme.tech/DL2053

Today I have found already some bugs...
When you input a future day, the program will still output '...was on a...'.
And I don't have something to make sure that the user cannot input a invalid dates for the month February...

That last one might be easy to fix, but for the first one I'll first have to find a way to check if the inputted date is in the past or the future...

Another bug: The ti-BASIC version won't let you change the year/month your country switched to the Gregorian calendar.

Ah, I see...
There I probably didn't change the pause command...
In ICE you can use Pause as a Wait (sort of) so I used Pause 500, with 500 being the time in milliseconds.
Three times to add a dot after the text.
You'll see that when you press enter..
(That's how I found it that fast)

I've today worked actually very fast on fixing the bugs.
The bugs should be fixed now, so I'm uploading the new versions to the archives.
I hope that were all the big bugs, but if you still find any bug, after downloading the new version, feel free to tell it.

Aaaand.... found a new bug...
I already know how to fix that, it's only the BASIC version.
Will fix that today
Edit:
And I've found even more bugs...
The BASIC version doesn't give an error when you put in as month 0.
And both versions have that for the month. ...

And then there are some features I should add...
I'm going to add a way to see which version you have and I want to change something in the configuration part.
However, that last thing is something for version 1.2.0, first working on fixing bugs and adding that you can see which version you have. (That will be 1.1.1)

I've fixed the bugs and added the feature of seeing which version you have!
I've also already changed the configuration part a bit.
Now you can also move up instead of only down with as last point QUIT.

I hope this were all the big bugs...
You can download the new version once it has been approved by an archive moderator. (they'll be thinking I will never stop fixing bugs and uploading it again the day after I uploaded the previous version ....)
But if you still find any, feel free to send me an email!

BTW, I decided to name this version already as version 1.2.0, because I already added stuff.

I've already been notified of a new bug...
That's that the program doesn't give an error when you input a date that is between the last Julian date and the first Gregorian date...
So if you changed on 4 October 1582, and input the non-existing date 5 October 1582, you won't get an error...
However, it should be loss to fix that, but I first need to do a little bit research though.

But I will now wait until there are multiple bugs, and then fix them all at the same time.
That to make sure I don't find a bug just after uploading a new version.
I will also let new versions been tested more thoroughly.

Because there are some bugs with the settings, which are currently saved in variables, I decided to try if it's possible to save it instead in a matrix.
Because variables are more used than matrixes as far as I know, I think that saving it in matrixes is better, because then there's less change that the settings will be deleted or overwritten by accident.

So in the next version the settings will be saved in matrixes.

Pfffff...
Fixing the bug of not getting an error when you input a date which doesn't exist due to the change from Julian to Gregorian calendar is hard...
I have to use complex If statements, which aren't really easy to understand for me, right after writing them down...
I just wrote it down and thought: 'what was that actually doing?'

But now I've the first statement finished, so nine to go.....
And then I only have the dates that are in the same month...
So if the calendar changed on a 22th of a month, it wouldn't work for every date anymore.....

What I now use is:

Code:


I hope I can find a way to make it also possible for the case I described above that aren't giving an error still, with this code, that they will give errors....
So if anyone knows how to do that....

I've now got the program working, but.....
It's now waaaay to big....

Yesterday in the Discord some people came with ideas, so I'll have a look at that today. And when I was laying in my bed and couldn't sleep, I thought of a way I could remove very much lines.
Now I've three times the same code, but if I set a variable for the three different scenarios I can get the same effect with the code just one time.