On Tue, 11 Apr 2006 17:10:45 -0400, Walter Bright <newshound@digitalmars.com> wrote:

> Thanks to all who said 'thanks.' Your appreciation makes it all worthwhile for me.

I don't say it enough (or at all), so thanks!

Even if D does not become a success, a lot of us have learned a lot along the way, and that's all what really matters to me.

- Chris

Chris Miller wrote:
> On Tue, 11 Apr 2006 17:10:45 -0400, Walter Bright <newshound@digitalmars.com> wrote:
> 
>> Thanks to all who said 'thanks.' Your appreciation makes it all worthwhile for me.
> 
> I don't say it enough (or at all), so thanks!
> 
> Even if D does not become a success, a lot of us have learned a lot along the way, and that's all what really matters to me.
> 
> - Chris


Totally agree!

-JJR

Walter Bright wrote:
> Bug fixes.
> 
> http://www.digitalmars.com/d/changelog.html

"Changed parameter types for std.date.MakeDate and std.date.MakeTime so they won't overflow."

What you've done here makes no sense to me.  Why is abusing the d_time type necessary to prevent an overflow?  I.e. how does any of the following:

- making the parameters long, considering that d_time is an alias of long anyway
- casting the ints to longs within the function
- making TicksPerHour et al long

still lead to an overflow?

I refer you back to

http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D.bugs/2365

Also, why are none of the Make* and *FromTime functions documented?

Stewart.

Yep, its been a fun ride :D.  Thanks from me too.

Charlie



John Reimer wrote:
> Chris Miller wrote:
> 
>> On Tue, 11 Apr 2006 17:10:45 -0400, Walter Bright <newshound@digitalmars.com> wrote:
>>
>>> Thanks to all who said 'thanks.' Your appreciation makes it all worthwhile for me.
>>
>>
>> I don't say it enough (or at all), so thanks!
>>
>> Even if D does not become a success, a lot of us have learned a lot along the way, and that's all what really matters to me.
>>
>> - Chris
> 
> 
> 
> Totally agree!
> 
> -JJR

Stewart Gordon wrote:
> Walter Bright wrote:
>> Bug fixes.
>>
>> http://www.digitalmars.com/d/changelog.html
> 
> "Changed parameter types for std.date.MakeDate and std.date.MakeTime so they won't overflow."
> 
> What you've done here makes no sense to me.  Why is abusing the d_time type necessary to prevent an overflow?  I.e. how does any of the following:
> 
> - making the parameters long, considering that d_time is an alias of long anyway
> - casting the ints to longs within the function
> - making TicksPerHour et al long
> 
> still lead to an overflow?

Because sometimes very large values are passed to these functions. I have a test app that does that.


> Also, why are none of the Make* and *FromTime functions documented?

Sloth on my part.

Walter Bright wrote:
> Stewart Gordon wrote:
<snip>
>> What you've done here makes no sense to me.  Why is abusing the d_time type necessary to prevent an overflow?  I.e. how does any of the following:
>>
>> - making the parameters long, considering that d_time is an alias of long anyway
>> - casting the ints to longs within the function
>> - making TicksPerHour et al long
>>
>> still lead to an overflow?
> 
> Because sometimes very large values are passed to these functions. I have a test app that does that.

But what is the practical use of being able to pass such huge arguments as the day or month?

Still, people are no doubt already confused by the idea that you're supposed to pass a number of milliseconds since 1970 as the year, month, day, hour, minute, second or millisecond component when constructing a date/time.  At least, these parameters should be long rather than d_time.  Unless I'm missing something then there's nothing to lose, and some sanity in the code (and eventual documentation) to gain.

Stewart.

Stewart Gordon wrote:
> Walter Bright wrote:
>> Because sometimes very large values are passed to these functions. I have a test app that does that.
> But what is the practical use of being able to pass such huge arguments as the day or month?

Test programs often aren't practical; they test the limits. And the limits should work without silent overflow.


> Still, people are no doubt already confused by the idea that you're supposed to pass a number of milliseconds since 1970 as the year, month, day, hour, minute, second or millisecond component when constructing a date/time.

The only thing confusing is it isn't documented.

> At least, these parameters should be long rather than d_time.  Unless I'm missing something then there's nothing to lose, and some sanity in the code (and eventual documentation) to gain.
> 
> Stewart.