mIRC Home    About    Download    Register    News    Help

Print Thread
64 bit time values #263061 21/05/18 09:36 PM
Joined: Jan 2004
Posts: 1,178
maroon Offline OP
Hoopy frood
OP Offline
Hoopy frood
Joined: Jan 2004
Posts: 1,178
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.

Last edited by maroon; 21/05/18 10:01 PM.
Re: 64 bit time values [Re: maroon] #263065 22/05/18 03:15 AM
Joined: Feb 2003
Posts: 2,642
Raccoon Offline
Hoopy frood
Offline
Hoopy frood
Joined: Feb 2003
Posts: 2,642
> 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).


Well. At least I won lunch.
Good philosophy, see good in bad, I like!
Re: 64 bit time values [Re: maroon] #263068 22/05/18 03:08 PM
Joined: Dec 2002
Posts: 4,521
Khaled Offline
Hoopy frood
Offline
Hoopy frood
Joined: Dec 2002
Posts: 4,521
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.

Re: 64 bit time values [Re: Khaled] #263220 16/06/18 01:40 AM
Joined: Jan 2004
Posts: 1,178
maroon Offline OP
Hoopy frood
OP Offline
Hoopy frood
Joined: Jan 2004
Posts: 1,178
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)


Re: 64 bit time values [Re: maroon] #263226 16/06/18 04:53 PM
Joined: Dec 2002
Posts: 4,521
Khaled Offline
Hoopy frood
Offline
Hoopy frood
Joined: Dec 2002
Posts: 4,521
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.

Re: 64 bit time values [Re: Khaled] #263227 16/06/18 05:46 PM
Joined: Jan 2004
Posts: 1,178
maroon Offline OP
Hoopy frood
OP Offline
Hoopy frood
Joined: Jan 2004
Posts: 1,178
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) )

Re: 64 bit time values [Re: maroon] #263230 16/06/18 07:45 PM
Joined: Dec 2002
Posts: 4,521
Khaled Offline
Hoopy frood
Offline
Hoopy frood
Joined: Dec 2002
Posts: 4,521
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.