On Sunday, 31 March 2013 at 02:39:48 UTC, Steven Schveighoffer wrote:
>> 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.

Or they may treat it heuristically. C standard says that time_t is implementation defined, so if you want to know which time it represents, you should use gmtime function which converts it to broken down form - year, month etc.

On Sunday, 31 March 2013 at 02:39:48 UTC, Steven Schveighoffer wrote:
> It won't be very long until Unix will have to tackle this (hopefully they don't wait until 2037).

It looks like time_t is 64-bit on 64-bit system
http://svnweb.freebsd.org/base/head/sys/x86/include/_types.h?view=markup
So the issue is probably solved by migration to 64-bit, which can be done before 2037.

On Saturday, March 30, 2013 22:39:49 Steven Schveighoffer wrote:
> What C stuff am I interacting with?  Unix Time <=> SysTime conversions are purely D code.

If you're using pure D code, then why are you using unix time at all? I would expect the need for unix time in pure D code to be extremely rare. Pretty much the whole reason that unix time is supported in the first place is because that's what C uses. If we'd never had to worry about C, then there shouldn't have been much need for it.

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

As I understand it, that _is_ the solution. Most everything is moving to 64- bit anyway.

> D will be more ready for that with a change to
> long/ulong for unixTimeToSysTime.

We're ready for that already with time_t. If time_t isn't 64-bit on your system when 2038 comes, you're screwed anyway as long as you're dealing with time_t.

I'm not completely against changing what unixTimeToSysTime takes, but unix time is very much tied to time_t, and I really don't buy that it buys us much to make it take a long.

- Jonathan M Davis

On Sun, 31 Mar 2013 06:00:53 -0400, Lars T. Kyllingstad <public@kyllingen.net> wrote:

> On Saturday, 30 March 2013 at 02:46:27 UTC, Steven Schveighoffer wrote:
>> On Fri, 29 Mar 2013 18:08:28 -0400, Jonathan M Davis <jmdavisProg@gmx.com> wrote:
>>
>>> std.conv.to is the standard way to convert one type to another. I see no
>>> reason to introduce stuff specific to core.time or std.datetime to do
>>> conversions. It should just hook into the standard stuff for that. If
>>> everything uses std.conv.to for coverting between types, then you don't have
>>> to worry about figuring out how a particular programmer decided that their API
>>> should do it - be it with casts or asOtherType toOtherType or whatever.
>>> std.conv.to is specifically designed so that any type can hook their own
>>> conversions into it, and then you can just always use std.conv.to for
>>> converting types.
>>
>> But the one doing the work is core.time.  In essence, you have locked away part of the API behind cast, and in order to get it out without using cast, you have to import another module.
>>
>> opCast is just a function, it could easily be called opTo, or simply to(T)().
>
> Now that we have the UFCS, std.conv.to should simply be implemented as:
>
>     T to(F, T)(F from)
>     {
>         T t;
>         from.convert(t);
>         return t;
>     }
>
> Then, std.conv should provide convert() functions for built-in types, e.g.
>
>    void convert(wstring from, ref string to);
>    void convert(long from, ref int to);
>    etc.
>
> User-defined types could define their own convert method:
>
>    struct MyType
>    {
>       void convert(ref MyOtherType tgt);
>    }
>
> This is both safer and more flexible than using opCast(), since
>
>   1. you avoid the unfortunate association with the cast operator,
>   2. convert() can be virtual if desired,
>   3. convert() can be called directly to modify the target variable in-place.

I don't think this is flexible enough.  It may not be enough to be able to fill in another type.

But we don't need to go through ANY of this, just change T opCast(T)() to T to(T)().

This way, with UFCS, a.to!B() will either call the method if available, or std.conv.to (assuming it's imported).

-Steve