Atari Timewise Max Date is Dec 31, 1999....

[gilsaluki]

I tried to enter today's date in Atari's Timewise program (DX5047), it kept giving me "Input a valid date" message.  So, I kept backing up the date till it liked one.  The latest date it would accept is Dec 31, 1999.   I guess they had no clue that someone would STILL be trying to use the thing in the next century.   Is there an updated version, corrected to allow current dates, for this program.  Or should this disk just be a museum piece?

[erichenneke]

Oh my,  a Y2K flashback!  

[Gunstar]

Can it be set as 0020 or 1020? ? Really, I'm thinking if you can go back to a time were the dates and days, etc. would match up to where we are at today...?

[_The Doctor__]

the days will be wrong or the date will be wrong the two will not match up, so you can match day or month and name of day but not year.... the Y2k fix for most of this stuff should be trivial these days especially with the emulators and tools available.... I'm sure there will be a hero to do it... :)

[BillC]

16 hours ago, _The Doctor__ said:

the days will be wrong or the date will be wrong the two will not match up, so you can match day or month and name of day but not year.... the Y2k fix for most of this stuff should be trivial these days especially with the emulators and tools available.... I'm sure there will be a hero to do it...

There are only 14 possible annual calendars, the variables are the day the year starts and whether it is a leap year.

Since 2020 is a leap year and starts on Wednesday I did a web search and found that this usually happens every 28 years, of the years listed Timewise will only accept 1992. This means that Timewise should display the correct day of the week for a date in 2020 if the year is set to 1992.

Edited June 2, 2020 by BillC

[+CharlieChaplin]

Yep,

the same Y2K problem happens in many A8 calendars, Biorhythm programs and other programs that require a date. If you simply type in "20" they most often will list it as 1920. Wow, an Atari 8Bit in 1920... 

 

[_The Doctor__]

exactly we get the day/month but not the year... to get by, but patching these up for real is the way to go... just add to the year for display? of actually fix the guts? there were forever calculators that did the calendar for eternity so the code can't be too terrible...

Edited June 2, 2020 by _The Doctor__

[Gunstar]

38 minutes ago, BillC said:

There are only 14 possible annual calendars, the variables are the day the year starts and whether it is a leap year.

Since 2020 is a leap year and starts on Wednesday I did a web search and found that this usually happens every 28 years, of the years listed Timewise will only accept 1992. This means that Timewise should display the correct day of the week for a date in 2020 if the year is set to 1992.

While I'm all for a true fix, as long as I can get the correct date and day of the week, I think I can stand the year being wrong since I think I can keep track of it myself. Were I to use this or similar programs. So if I start using this program again (I did use it for my college schedule back in the 90's) setting the year as 1992 or 93 (assuming I may not start using it again this year) is good enough for me. Thanks for the calculations or research you did @BillC , I knew the dates and days had to line up with today at some point in the past.

Edited June 2, 2020 by Gunstar

[bfollowell]

I never used Timewise back in the day, and certainly wouldn't use it today, but I can appreciate those that do wanting it to work correctly. I see that it requires BASIC, so can I assume that it is actually a BASIC program?

 

If so, I wouldn't think it would be too hard to correct whatever subroutines control date entry and date calculations if someone were so inclined to do so. I guess it all depends on how well written, organized, and documented the program is. The most direct method would seem to be to update any date entry, calculation, and storage subroutines to only allow four digit years. Of course, that would slightly increase the record storage size, so that would impact how many records could be stored, but it would probably worth the trade-off to those wanting to use the program today.

 

 

Edited June 2, 2020 by bfollowell

[gilsaluki]

I am not sure if it is indeed written in pure Basic.  I am thinking there are some assembly routines mixed in.  I found the book/documentation for it.  It clearly states that it will accept dates from 1982 to 1999.  I guess that seemed like along time back then.  The screens are really nicely drawn and the program is sensible, well laid out.  Too bad.  I know the program is not really practical in today's era (Outlook has a dandy calendar), but I just wanted to play with in on my real Atari 8.  I know nothing about programming, so I am out. 

[chevymad]

I would think one could reset the "19" to "20" and then change the day to date correlation in the software. Seems like that would be easier then changing everything to a 4digit year.  But it's been over 30 years since I've done any programming.. so won't be me either.

[Guest]

On 6/2/2020 at 4:16 AM, Gunstar said:

Can it be set as 0020 or 1020? ? Really, I'm thinking if you can go back to a time were the dates and days, etc. would match up to where we are at today...?

would this be possible? i have a feeling that most 1990s software had a "year zero" default of January 1, 1970

On 6/2/2020 at 9:07 PM, Gunstar said:

While I'm all for a true fix, as long as I can get the correct date and day of the week, I think I can stand the year being wrong since I think I can keep track of it myself. Were I to use this or similar programs. So if I start using this program again (I did use it for my college schedule back in the 90's) setting the year as 1992 or 93 (assuming I may not start using it again this year) is good enough for me. Thanks for the calculations or research you did @BillC , I knew the dates and days had to line up with today at some point in the past.

again, this is a good little workaround, but one to be careful with. for instance; 2020 is a leap year., so in reality this fix would need to not just line up the correct day/date combination, but also need to be another leap year. so in this instance, only 1984, 1988, 1992 and 1996 can be used.

it becomes a little more complicated if you're intending to use any of those files in future years. with your workaround the earlier dates are the best bet.

consequently, anyone creating a new file in Timewise would need to be aware of the correct starting point (date).

 

new file creation.................start dates to use

2020................................1984, 1988, 1992, 1996*

2021................................1985, 1989, 1993, 1997*

2022................................1986, 1990, 1994, 1998*

2023................................1987, 1991, 1995, 1999*

 

* do not allow much scope for future use/updates

 

Edited June 7, 2020 by Guest

[gilsaluki]

This has worked for me.  Would the next series of numbers for 2024 be:

1988,1992,1996,XXXX?