Nmap 7.90 broken script scan on Windows in UTC+n time zones

[cnotin]

Describe the bug
I get this error in afp.lua and the scan stops:

time result cannot be represented in this installation

To Reproduce
Run a very simple script scan on Windows:

nmap -sC 192.168.0.1
Starting Nmap 7.90 ( https://nmap.org ) at 2020-10-04 00:38 Paris, Madrid (heure d?ÚtÚ)
NSE: Failed to load C:\Program Files (x86)\Nmap/scripts\afp-serverinfo.nse:
C:\Program Files (x86)\Nmap/nselib/afp.lua:353: time result cannot be represented in this installation
stack traceback:
        [C]: in function 'os.time'
        C:\Program Files (x86)\Nmap/nselib/afp.lua:353: in main chunk
        [C]: in function 'require'
        C:\Program Files (x86)\Nmap/scripts\afp-serverinfo.nse:1: in function <C:\Program Files (x86)\Nmap/scripts\afp-serverinfo.nse:1>
NSE: failed to initialize the script engine:
C:\Program Files (x86)\Nmap/nse_main.lua:614: could not load script

Expected behavior
No error :)

Version info (please complete the following information):

• OS: Windows 10 2004
• Output of nmap --version:

Nmap version 7.90 ( https://nmap.org )
Platform: i686-pc-windows-windows
Compiled with: nmap-liblua-5.3.5 openssl-1.1.1h nmap-libssh2-1.9.0 nmap-libz-1.2.11 nmap-libpcre-7.6 Npcap-1.00 nmap-libdnet-1.12 ipv6
Compiled without:
Available nsock engines: iocp poll select

Additional context
I have isolated the error from this code:

os.time{year=1970, month=1, day=1, hour=0}

From:

nmap/nselib/afp.lua

Line 353 in 05ad57d

local TIME_OFFSET = os.time{year=2000, month=1, day=1, hour=0} - os.time{year=1970, month=1, day=1, hour=0}

There is no issue on Linux though... It seems to come from how Lua handles dates on Windows like in #1303

Also, but you are probably already aware, the "loslib.c" Lua file is outdated from upstream. I noticed it because in Nmap both os_date and os_time print "time result cannot be represented in this installation" instead of having os_date use "date result cannot..."

nmap/liblua/loslib.c

Line 297 in c76424d

"time result cannot be represented in this installation");

https://github.com/lua/lua/blob/9f791535cde1539338f6ba1b9154006595d97fe7/loslib.c#L318

[cnotin]

Interesting thing from mktime on MSDN (emphasis mine)

After an adjustment to UTC, _mktime32 handles dates from midnight, January 1, 1970, to 23:59:59 January 18, 2038, UTC. _mktime64 handles dates from midnight, January 1, 1970 to 23:59:59, December 31, 3000. This adjustment may cause these functions to return -1 (cast to time_t, __time32_t or __time64_t) even though the date you specify is within range. For example, if you are in Cairo, Egypt, which is two hours ahead of UTC, two hours will first be subtracted from the date you specify in timeptr; this may now put your date out of range.

I'm indeed in CEST timezone which is UTC+2

[cnotin]

I guess os.time{year=1970, month=1, day=1, hour=0} is supposed to be equal to 0 so a simple solution would be to replace it :)

[cnotin]

Indeed if we execute:

print(os.time{year=2000, month=1, day=1, hour=0} - os.time{year=1970, month=1, day=1, hour=0})

We get "946684800" which is the offset we want as confirmed in Wireshark dissector:
https://github.com/wireshark/wireshark/blob/607831d8706ae32781a4f9176f46cf72414d7b1e/epan/dissectors/packet-afp.c#L1267

[nnposter]

Excellent research into the root cause!

Hopefully fixed in commit r38083.

[cnotin]

Thanks! I hope too!