Rant: Date and Time fall short of simplicity in D

[Steven Schveighoffer]

On Sat, 30 Mar 2013 02:06:14 -0400, Jonathan M Davis <jmdavisProg at gmx.com>  
wrote:

> 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.

No, you are operating on an integer.  Unix time is defined as the number  
of seconds since 1/1/1970.  time_t is what time() returns, there is no  
requirement for unix time to ALWAYS be stored as a time_t.

> 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

toUnixTime can return time_t, which can implicitly cast to long or ulong.   
It's the *from* unix time that is a problem.

I'd argue that we probably should make it return long or ulong (I think I  
did that in Tango's time code), but that is something that can be done  
later.

> and I'd expect
> unixTimeToStdTime or unixTimeToSysTime to use the same type as  
> toUnixTime.

It should accept the type that has the most utility -- long or ulong.  As  
long as it accepts time_t without any loss, it does not harm anything.

> 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.

What C stuff am I interacting with?  Unix Time <=> SysTime conversions are  
purely D code.

It won't be very long until Unix will have to tackle this (hopefully they  
don't wait until 2037).  The most likely scenario is they just increase  
the bits for time_t to 64.  D will be more ready for that with a change to  
long/ulong for unixTimeToSysTime.

-Steve