Beta 7.52.425 and 7.52.431
4.Item 4, changed. This affects all features that use time values such as script identifiers/commands eg. $asctime()/$ctime/etc., features that stores file times eg. script file change monitor, measure time differences eg. DCC send/get, and so on.
Regarding 64bit time values, is this intended to increase ctime values only to the arbitrary cutoff of year 3000 or is that caused by the library being used?
--
Are there other changes that will eventually will give some kind of $ticks-style precision smaller than milliseconds? Such as the microseconds value from QueryPerformanceCounter? Either as another identifier or as a .prop
--
Edit: this one happens as far back as v7.38, and may relate to item 25 or 36 in v7.37's change log.
Incorrect handling of 1 second before midnight 1/1/every-year
1 second before midnight of each year 1970-2999 reports 1 second before midnight for Jan 31st of the following year. Also happens for the 2 digit years, including 69 recognized as if 1969. This should display 1030 lines:
//var %i 1970 | while (%i isnum 1970-2999) { var %a $ctime(31/12/ $+ %i 23:59:59 ) | if (*Jan 31 23:59:59* !iswm $asctime(%a)) echo -a year %i vs $v2 | inc %i }
--
$ctime's 2-digit pivot-year should be increased
Since the valid year range is no longer 69-38, the pivot date for 2 digit years should increase to at least 68 for 2068.
Since there are valid ctimes for the last few hours of 31/12/69, 2 digit years should not be associated with 2069, unless Dec 30th and earlier are handle differently. Even though 31/12/69 can be a valid $ctime date for 1969, ctime doesn't allow using 1969 as a 4 digit year:
//echo -a $ctime(31/12/69 23:59:58) vs $ctime(31/12/1969 23:59:58)
Note: This should only return values for timezone settings west of GMT
--
Inconsistent max valid $file().mtime numeric
Also, the max value returned by $file(file).mtime is not consistent by timezone. The max value returned by .mtime is the lesser of 32535244799 or the ctime value from time string "Wed Dec 31 23:59:59 3000" in the local zone. This ctime numeric is 1 minute before midnight in the USA Pacific Daylight, so the maximum filetime translated to .mtime is that date/time-string for that timezone and eastward, but timezones like Hawaii won't display the .mtime for files unless they display timestrings that are 1 or more hours earlier than that.
--
And before anyone else says there's no need to deal with dates in the distant future, there are at least a couple ways they can be useful.
1. I've seen programs used by Human Resource which filled the 'termination date' for all active employees as a date in the distant future that would not print along with the other modern dates, making it simpler to identify active employees as of a target date because that date was between the hire/term dates, while still printing reports for active employees showing a blank term date.
2. 1/1/2000 and 1/1/2400 and 1/1/2800 are all the same day of the week, so all days of the week from years 1583-1970 would be the same day of the week as years 2383-2770, so you could find days of the week for 1583-1999 by using century 23-27 in place of century 15-19.
//echo -a Jul 4th 1776 was a $asctime( $ctime(4/7/2576 0:0) ,dddd)
For extending the Gregorian calendar prior to Oct 1582, can take advantage of Jan 1st 1500 being the same day of the week as Jan 1st for years 2200/2600/3000.
