How to recognize different types of sentinel timestamps from quite a long way away

A puzzle: Why are so many fake LiveJournal blogs written by 29-year-olds?

The Old New Thing — Thu, 07 May 2009 17:26:18 GMT

At least we think they're fake.

Real Life Debugged » Blog Archive » Yo, Today is December 31, 1969?

Wed, 22 Apr 2009 15:56:04 GMT

PingBack from http://www.lisaksimone.com/phoneonfire/2009/04/22/yo-today-is-december-31-1969/

re: How to recognize different types of sentinel timestamps from quite a long way away

John — Wed, 02 Nov 2005 15:12:13 GMT

The time_t typedef is a relatively recent invention, created during the the ANSI C standardization process, IIRC. The original Unix definition of time() and related functions used "long".

re: How to recognize different types of sentinel timestamps from quite a long way away

Norman Diamond — Tue, 01 Nov 2005 04:34:04 GMT

Monday, October 31, 2005 2:07 PM by Ben Hutchings
> Norman: The Gregorian calendar was adopted
> in most Roman Catholic countries in 1582.

Yikes. I was 100 years off. I'd better stop relying on memory before talking about non-computer stuff that way.

I even have enough discipline to look up which argument is which in functions like memcpy almost every time I use them (because memcpy and bcopy had them in opposite orders and if I try to remember which is which then I'll remember wrong). So I really was out of line by not looking up centuries. I am duly chastised.

Geez, a century. That might even be enough time for Windows Vista beta 1 checked build to finish installing itself.

re: How to recognize different types of sentinel timestamps from quite a long way away

martynl — Tue, 01 Nov 2005 01:20:07 GMT

In VC8 (Whidbey) which just RTMed (WooHoo!), we widened time_t to 64 bits by default. It is still signed.

You can use a #define to switch back to 32 bit time.

We also provide specifically named time functions for the 32 bit and 64 bit versions of the type.

Martyn Lovell
Development Lead
Visual C++ Libraries

re: How to recognize different types of sentinel timestamps from quite a long way away

Ben Hutchings — Mon, 31 Oct 2005 21:07:54 GMT

Norman: The Gregorian calendar was adopted in most Roman Catholic countries in 1582. Britain and its colonies (including what is now the US), being Protestant by then, were slow to change over, though not as slow as e.g. Russia.

re: How to recognize different types of sentinel timestamps from quite a long way away

Andreas Magnusson — Mon, 31 Oct 2005 09:54:40 GMT

Yay, so in another 33 years we'll have another possible Y2K! Ok guys, this time we make it right! We need to scare the crap out of everyday users about the EOW so that they pay us a lot of money for fixing it!
We must henceforth use signed time_t for all times and dates in our software, especially any software going into nuclear reactors!

Good luck! I'm counting on you guys!

re: How to recognize different types of sentinel timestamps from quite a long way away

Norman Diamond — Mon, 31 Oct 2005 05:36:40 GMT

> All of these special values have one thing
> in common: If you see them, it's probably a
> bug.

All except one. If you see the special value December 31, 1969, it's probably intentional. Still unwanted but usually intentional.

Friday, October 28, 2005 10:39 AM by Carlos
> Leap years follow a 400 year cycle, with
> 1600, 2000, etc. being the "most significant"
> special case.

Actually only 2000 is, so far. 1600 is useful for computational purposes by pretending that it was part of the same cycle, but when Christians were counting 1600 years Pope Gregory hadn't been invented yet.

re: How to recognize different types of sentinel timestamps from quite a long way away

asdf — Sat, 29 Oct 2005 06:36:13 GMT

time_t is a signed integer for historical reasons:
- dates all the way back to when C didn't have unsigned integers
- unix's time_t is signed and the year 2038 is plenty enough of time to switch over to 64 bits. Today's programmers will be either dead or retired in that year, so it's somebody else's problem
- lots of crappy programmers assume it's signed and do subtraction on it instead of using difftime and expect it to be a negative value if the dates are backwards (even though this doesn't handle large distances correctly)
- functions return (clock_t)-1 on error and due to C's (IMHO stupid) way of doing arithmetic conversions on the comparison operators, this can result in the wrong result on some platforms under certain conditions

C trivia: time_t/clock_t are allowed to be any arithmetic type including an unsigned integer or floating point type.

re: How to recognize different types of sentinel timestamps from quite a long way away

Raymond Chen - MSFT — Fri, 28 Oct 2005 22:17:59 GMT

Bryan: Yes, sometimes the value is signed and sometimes it's unsigned. The interpretation should be clear from context.

"Any given unix-like system should treat them either as unsigned or signed, not both."

Right, but you the end user might have to deal multiple machines, some which use the signed interpretation and some which use the unsigned interpretation. So I included both, because the goal of the table was to show everything you might encounter. Writing "The value 0x80000000 as a time_t when interpreted on a system for which time_t is a signed type" would have been more precise but would have cluttered the table with information that really isn't relevant to the main point: Recognizing sentinel values.