mIRC Home    About    Download    Register    News    Help

Topic Options
#263061 - 21/05/18 10:36 PM 64 bit time values
maroon Offline
Hoopy frood

Registered: 12/01/04
Posts: 1056
Beta 7.52.425 and 7.52.431

Quote:

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:

Code:
//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:

Code:
//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.

Code:
//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.


Edited by maroon (21/05/18 11:01 PM)

Top
#263065 - 22/05/18 04:15 AM Re: 64 bit time values [Re: maroon]
Raccoon Offline
Hoopy frood

Registered: 18/02/03
Posts: 2541
> 4.Item 4, changed.

I believe this was where Khaled fixed the bugs where scripts would register as having changed after daylight savings. There were inconsistencies between API calls, and I think Khaled did a unification to iron those issues out. I don't think CTIME (unix time) as a 32 or 64 bit number format is related to this.

I don't know that UNIX time has taken an official update to address the Y2k38 bug. https://en.wikipedia.org/wiki/Year_2038_problem

What would you do with microseconds in such a spongy scripting language? Except to manage file modified/creation dates-time values.

I would like to see a CTIME/ASCTIME that handles system clock milliseconds (only to system clock's resolution, ie, 64 or 100 Hz).
_________________________
At least I won lunch.
Good philosophy, see good in bad, I like!

Top
#263068 - 22/05/18 04:08 PM Re: 64 bit time values [Re: maroon]
Khaled Offline


Planetary brain

Registered: 04/12/02
Posts: 4343
Loc: London, UK
Quote:
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?

The only change that was made was to switch to 64bit time values by using the Windows 64bit time APIs instead of the 32bit time APIs. This is part of the process of preparing mIRC to compile as a 64bit application, which still has a long way to go.

Top
#263220 - 16/06/18 02:40 AM Re: 64 bit time values [Re: Khaled]
maroon Offline
Hoopy frood

Registered: 12/01/04
Posts: 1056
Just confirming that the bugs are still there in the latest beta, including

Code:
//var %i 1970 , %range $iif($beta && $version isnum 7.52,1970-2999,1970-2037) | while (%i isnum %range) { 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 }

//echo -a $ctime(31/12/69 23:59:58) vs $ctime(31/12/1969 23:59:58)


Top
#263226 - 16/06/18 05:53 PM Re: 64 bit time values [Re: maroon]
Khaled Offline


Planetary brain

Registered: 04/12/02
Posts: 4343
Loc: London, UK
Quote:
//var %i 1970 , %range $iif($beta && $version isnum 7.52,1970-2999,1970-2037) | while (%i isnum %range) { 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 }

Thanks, this should be fixed in the next beta. That said, the specific change that needed to be made reversed a previous change that was made about a decade ago, apparently to fix a different issue. It's impossible to know exactly what that was since the code has changed so many times. This will need to be tested thoroughly in the next beta.

Quote:
//echo -a $ctime(31/12/69 23:59:58) vs $ctime(31/12/1969 23:59:58)

Note that this is not a bug. mIRC uses the Windows time APIs which are limited by their 32bit/64bit range.

Top
#263227 - 16/06/18 06:46 PM Re: 64 bit time values [Re: Khaled]
maroon Offline
Hoopy frood

Registered: 12/01/04
Posts: 1056
ok thanks. We found the bug in versions back as far as 7.38, so it seems related to fixing the daylight saving issue in:
https://forums.mirc.com/ubbthreads.php/topics/248878/7.36_Timestamp_not_correct#Post248878

And for the 2nd example, does this mean that 2-digit years will not be supported outside the original 32bit range ending in 2038? i.e. //echo -a $asctime( $ctime(31/12/39 23:59:58) )

Top
#263230 - 16/06/18 08:45 PM Re: 64 bit time values [Re: maroon]
Khaled Offline


Planetary brain

Registered: 04/12/02
Posts: 4343
Loc: London, UK
Quote:
ok thanks. We found the bug in versions back as far as 7.38, so it seems related to fixing the daylight saving issue in:
https://forums.mirc.com/ubbthreads.php/topics/248878/7.36_Timestamp_not_correct#Post248878

The code that has been changed existed as far back as v6.35.

Quote:
And for the 2nd example, does this mean that 2-digit years will not be supported outside the original 32bit range ending in 2038? i.e. //echo -a $asctime( $ctime(31/12/39 23:59:58) )

That's right, there are no plans to change this.

Top