[Review]Fix the potential 2038 issues

[wenshan1]

1. The length of long in a 32-bit system is 32 bits, which cannot be used to save timestamps after 2038.
   Most operating systems have extended time_t to 64 bits.
2. The return type of time() is time_t, the tv_sec type in struct timeval is time_t except windows.
   Possible loss of data caused by the following code:
   The code now.tv_sec = (long)time(NULL);
3. This pull request don't solve the 2038 issues in windows.

This changes is to remove the operation of casting to long.

[bagder]

There are also the reverse situation platforms with 64 bit long and 32 bit time_t...

[bagder]

Did you verify this patch on a system with 32 bit long and 64 bit time_t to see that it handles dates after 2038?

[wenshan1]

There are also the reverse situation platforms with 64 bit long and 32 bit time_t...

The win 64-bit use an abstract data model called LLP64 (or P64).
https://docs.microsoft.com/en-us/windows/win32/winprog64/abstract-data-models

[bagder]

There are also the reverse situation platforms with 64 bit long and 32 bit time_t...

The win 64-bit use an abstract data model called LLP64 (or P64).
https://docs.microsoft.com/en-us/windows/win32/winprog64/abstract-data-models

I was not referring to Windows. I'm pretty sure (early?) AIX versions work like I explained.

[wenshan1]

There are also the reverse situation platforms with 64 bit long and 32 bit time_t...

The win 64-bit use an abstract data model called LLP64 (or P64).
https://docs.microsoft.com/en-us/windows/win32/winprog64/abstract-data-models

I was not referring to Windows. I'm pretty sure (early?) AIX versions work like I explained.

AIX

If AIX is posix compatible system, I think my PR don't introduce a new issue even if the platform is 64-bit long and 32-bit time_t.

[bagder]

Thanks!