look for any Y2038 problems in Tahoe-LAFS or its dependencies

[daira]

I don't know of any, but thought it would be nice to grab this ticket number :-)

[daira]

wiki:SftpFrontend documents this issue: "The SFTP protocol and the server are able to represent dates up to the year 2106, but some clients may print dates incorrectly after 2037."

[gdt]

Probably this ticket should be narrowed to "look for Y2038 problems when tahoe is built on a system that has fixed system-wide Y2038 issues".

Specifically, a large part of this it moving to 64-bit time_t (usually int64_t). NetBSD 6 did this, and I'd imagine that all other systems are doing this over the last few or next few years. Of course, there could well be issues with wire encodings, and using unsigned long instead of time_t locally.

[daira]

Yes, I'm assuming that Python and the operating system are someone else's problem (as long as we are using Python APIs that can support post-2038 dates).

[daira]

​http://stackoverflow.com/questions/839755/how-to-use-time-year-2038-on-official-windows-python-2-5 says that Python >= 2.6 uses 64-bit time_t on Windows. For Unix it presumably depends on however the OS ABI defines time_t.

[daira]

Linux Mint (64-bit):

$ uname -a
Linux katava 3.2.0-4-amd64 #1 SMP Debian 3.2.32-1 x86_64 GNU/Linux

$ python
Python 2.7.3rc2 (default, Apr 22 2012, 22:30:17) 
[GCC 4.6.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from datetime import datetime
>>> datetime(1L<<31)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
OverflowError: signed integer is greater than maximum

I'm not going to set my date to 2038 on my working desktop to test this more thoroughly :-). Anyone have a spare VM they want to do that on?

[gdt]

os x 10.6, python2.7, built -mi386: matches your result NetBSD 6, i386: OverflowError?: Python int too large to convert to C long NetBSD 5, i386 (time_t is long, 32 bits): OverflowError?: Python int too large to convert to C long

so it seems python has some issues.

[zooko]

To test whether Tahoe-LAFS source code handles such large numbers, we don't need to set our system clocks, but instead have a unit test which patches time.time and has it return a large number, and then the unit test exercises the Tahoe-LAFS code that is affected by the return value from time.time.

[daira]

Replying to zooko:

To test whether Tahoe-LAFS source code handles such large numbers, we don't need to set our system clocks, but instead have a unit test which patches time.time and has it return a large number, and then the unit test exercises the Tahoe-LAFS code that is affected by the return value from time.time.

Well, that's not necessarily sufficient, because there are quite a few more time/date-related Python APIs than time.time. I think we need to first enumerate which time/date APIs are used.