Implementing localtime, mktime, etc.

[Dave_Sinkula]

Has anyone ever rolled his own?

I'm in the process of doing so now. I've found some sources online, but either GPL or other copyrights seemed burdensome; or others used system functions unavailable to me. I've got the basics working for the moment, but I thought I'd seek advice before the concrete sets.

The underlying issue was to include Daylight Saving Time with both America and Europe in mind; also to have real year/month/day/hour/minute information in an event time stamp. And this time stamp needs to fit into 27 bits. I figured if you divide a (32- or) 31- bit (unsigned) long by 60 you can meet these requirements, so just use standard library stuff. But alas, I found only the header but no library code in the implementation.

Anyway, I've chosen an unsigned long for my basic tick and used January 1, 2000 as the start of my epoch. And a binary search of an array of 128 values that are the number of seconds elapsed to a particular year -- there is a little extra room in the unsigned long, but I wanted a "dead zone" for invalid dates and to make every path of the binary search use 8 times in the loop. This buys me 128 years and I could stamp it "Y2.038K OK" (I just know they'll ask for it at some point, and legacy code lingers on for an eternity).

Most of the code is straightforward, if not tedious. I'd post it, but as I've hinted, I am a little unsure of copyright stuff since it is not my personal code. But some of my questions are:

• Since I am (partly) implementing standard library routines, am I free to make the choice about how to define a time_t? Can I define it differently from the POSIX's time_t being a long?
• If I define my epoch differently from the POSIX's January 1, 1970 is this a great concern?

Now some of the point of this is to hopefully "play nice" with an existing Windows application. As such, I figure that retrieving the 27-bit y/m/d/h/m value, multiplying by 60 and adding an offset to Jan 1, 2000 might be a relatively simple method of handling on the PC end. But if there are issues I have overlooked, please let me know.

Thanks in advance.

[zacs7]

One problem I see is that, what if you want to represent a time before 2000? Starting from the year 2000 kinda throws compatibility out the window with the UNIX epoch, or am I missing the point?

Using time_t could also become confusing...

[Dave_Sinkula]

One problem I see is that, what if you want to represent a time before 2000? Starting from the year 2000 kinda throws compatibility out the window with the UNIX epoch, or am I missing the point?

I don't plan on representing times before the product is released, which is not yet.

Using time_t could also become confusing...

Do you mean defining my own time_t, which is by nature implementation-defined, on an implementation that does not define one? Or one that differs from most common implementations (POSIX) even though it can be "made POSIX" relatively easily by an external device interfacing with this one?

[zacs7]

I'm pretty sure it won't really matter how you define time_t,

[Salem]

time_t needs to be an arithmetic type (so simple assignment and relationships work).

But beyond that, you have a free hand as all the other time functions (mktime, difftime) hide how to convert a time_t into real time components such as seconds.

[quzah]

Maybe you could use a double, since it has such great precision. "Hell I said I'd be there at two. It's two-thirty, that's close enough!"


Quzah.

[Salem]

128 bit nanoseconds, with the big bang being the epoch