On Sat, 30 Mar 2013 02:06:14 -0400, Jonathan M Davis <[email protected]>
wrote:
On Friday, March 29, 2013 22:50:16 Steven Schveighoffer wrote:
On Fri, 29 Mar 2013 19:35:35 -0400, Jonathan M Davis
<[email protected]>
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
