On Friday, March 29, 2013 22:50:16 Steven Schveighoffer wrote: > On Fri, 29 Mar 2013 19:35:35 -0400, Jonathan M Davis <jmdavisp...@gmx.com> > > wrote: > > On Friday, March 29, 2013 10:03:31 Steven Schveighoffer wrote: > >> 1. unixTimeToStdTime should take ulong. > > > > Why? You're converting a time_t, so unixToStdTime explicitly uses > > time_t. Its > > size is system-dependent. > > Because if your unix time is stored in a ulong, for whatever reason, you > may then have to cast to call this function. > > time_t implicitly casts to ulong, no matter the system-defined size of > time_t. It's also more future-proof, for dates past 2038. > > Is there a specific reason to disallow accepting ulong?
Because the whole point is that you're operating on time_t, which isn't ulong. Also, specifically using an unsigned type is wrong, because time_t is signed on some systems. So, it could be changed to long, but using long instead time_t will break code on 32-bit systems for SysTime's toUnixTime, and I'd expect unixTimeToStdTime or unixTimeToSysTime to use the same type as toUnixTime. And if future-proofing is the issue, then you'll need a 64-bit system anyway, otherwise the C stuff that you're interacting with wouldn't work correctly with the larger time_t values. I can definitely see an argument for just using long and then requiring people to cast if they're really using time_t and are on a 32-bit system, but that would break code at this point. I used time_t, because the whole point was that you were converting to and from time_t. - Jonathan M Davis