Rant: Date and Time fall short of simplicity in D

[Jonathan M Davis]

On Friday, March 29, 2013 22:50:16 Steven Schveighoffer wrote:
> On Fri, 29 Mar 2013 19:35:35 -0400, Jonathan M Davis <jmdavisProg at 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