Remove "support" for unsigned time_t

I maintain that unsigned time_t does not actually exist, and that time_t is signed everywhere that matters. Further, we probably have all kinds of assumptions in our code that it is signed. So let's remove the "support" for unsigned time_t, since it probably wouldn't work anyway.

changed milestone to %Tor: 0.2.8.x-final

added component::core tor/tor milestone::Tor: 0.2.8.x-final owner::nickm points::small priority::low resolution::fixed severity::minor status::closed type::defect labels

Trac:
Status: new to accepted
Owner: N/A to nickm

We've also warned about this since 0.2.5.1-alpha, and nobody has complained.

It turns out that OpenVMS has had an unsigned time_t for a while, but afaik nobody builds Tor on OpenVMS. Signed time_t remains as a compile-time option there anyway.

See branch "bug18184" in my public repository.

Trac:
Priority: Medium to Low
Severity: Normal to Minor
Status: accepted to needs_review

Looks good to me.

Merging!

Trac:
Resolution: N/A to fixed
Status: needs_review to closed

Hi

I'm trying build tor for QNX, and met this errors when run configures.

"You have an unsigned time_t; Tor does not support that. Please tell the Tor developers about your interesting platform."

And QNX is using a unsigned 32-bit/64-bit number for time_t.

. The time_t data type is an unsigned 32-bit number, which extends this range for many applications through 2106. The kernel itself uses unsigned 64-bit numbers to count the nanoseconds since January 1970, and so can handle dates through 2554.

So I think we should reverse this ticket/merge.

http://www.qnx.com/developers/docs/660/index.jsp?topic=%2Fcom.qnx.doc.neutrino.sys_arch%2Ftopic%2Fkernel_CLOCKANDTIMER.html

Trac:
Username: ryankung
Reviewer: N/A to N/A

I've opened a new ticket (#21735 (moved)) for this. There's more to do here than just reverting the merge: We'd need to actually go through all our uses of time_t, and make sure that they don't rely on time_t being signed. Even though tor used to allow you to try to compile that way, we're pretty sure it never actually worked. More info on that ticket.

closed

mentioned in issue #21735 (moved)

moved to tpo/core/tor#18184 (closed)

mentioned in issue tpo/core/tor#21735 (closed)