View mode: basic / threaded / horizontal-split · Log in · Help
December 10, 2010
Re: Please vote on std.datetime
Fawzi Mohamed Wrote:

> Last thing, well is something I would have done differently (as I said  
> already in the past), is using doubles expressing number of seconds to  
> represent point in time, durations, and TimeOfDay. I know other  
> differs about this, but I really think that it is a very simple and  
> versatile type.

I actually have a problem with this format. I have an application that works with messages. The message has send date. The application was written in delphi so it uses double to represent DateTime. The message can be signed, the date can be included to the data to be signed, so the application uses the double format for sign buffer. Then I have .net application that should interoperate with delphi application, but you can't compute double value from string representation of DateTime in an interoperable way, the last bit depends on the order of computations, and if you miscompute it, the signatures will be incompatible.

I think, the point in time should be long, and millisecond precision is enough. Any higher precision is a very special case.
December 10, 2010
Re: Please vote on std.datetime
On Fri, 10 Dec 2010 15:14:11 -0500, Kagamin <spam@here.lot> wrote:

> Fawzi Mohamed Wrote:
>
>> Last thing, well is something I would have done differently (as I said
>> already in the past), is using doubles expressing number of seconds to
>> represent point in time, durations, and TimeOfDay. I know other
>> differs about this, but I really think that it is a very simple and
>> versatile type.
>
> I actually have a problem with this format. I have an application that  
> works with messages. The message has send date. The application was  
> written in delphi so it uses double to represent DateTime. The message  
> can be signed, the date can be included to the data to be signed, so the  
> application uses the double format for sign buffer. Then I have .net  
> application that should interoperate with delphi application, but you  
> can't compute double value from string representation of DateTime in an  
> interoperable way, the last bit depends on the order of computations,  
> and if you miscompute it, the signatures will be incompatible.
>
> I think, the point in time should be long, and millisecond precision is  
> enough. Any higher precision is a very special case.

longs as milliseconds = a range of +/- 300 million years.  I'd call that  
the special case.

The hnsecs as the base (100 nano-seconds) gives a range of +/- 30000  
years.  nanosecond ticks would yield +/- 300 years.  10 nanosecond ticks  
would yield +/- 3000 which is doable, but leaves our decendants to deal  
with the year 3000 problem (highly unlikely that anything like D will be  
still in use at that time, but still...).  I think 100-nsecs is a good  
choice for tick resolution.  It gives a very generous range for working  
with, plus is fine-grained enough to deal with many years of speed  
increases in processors.

Noteworthy is that Microsoft uses the same resolution (as does Tango), so  
there's at least anecdotal evidence that it's a natural choice for tick  
resolution.

-Steve
December 10, 2010
Re: Please vote on std.datetime
On 10-dic-10, at 21:14, Kagamin wrote:

> Fawzi Mohamed Wrote:
>
>> Last thing, well is something I would have done differently (as I  
>> said
>> already in the past), is using doubles expressing number of seconds  
>> to
>> represent point in time, durations, and TimeOfDay. I know other
>> differs about this, but I really think that it is a very simple and
>> versatile type.
>
> I actually have a problem with this format. I have an application  
> that works with messages. The message has send date. The application  
> was written in delphi so it uses double to represent DateTime. The  
> message can be signed, the date can be included to the data to be  
> signed, so the application uses the double format for sign buffer.  
> Then I have .net application that should interoperate with delphi  
> application, but you can't compute double value from string  
> representation of DateTime in an interoperable way, the last bit  
> depends on the order of computations, and if you miscompute it, the  
> signatures will be incompatible.
When signing normally one sends also the original message (with date),  
so I guess I don't understand your example, sorry...

And again I am *not* arguing to use double exclusively, just for  
absolute times, and as option for durations, and for the TimeOfDay

> I think, the point in time should be long, and millisecond precision  
> is enough. Any higher precision is a very special case.

but what is the problem if you do have it? that it is more difficult  
to guess the exact value you will read? why would any sane setting  
need that?
December 12, 2010
Re: Please vote on std.datetime
Steven Schveighoffer Wrote:

> I think 100-nsecs is a good choice for tick resolution.

My concern is millisecond is a SI unit, but hectonanosecond isn't, so I don't think, it's a good choice: it's hardly comprehensible.

> It gives a very generous range for working  
> with, plus is fine-grained enough to deal with many years of speed  
> increases in processors.

Clock and stopwatch have different usages. I think, it's no problem to design stopwatch with tunable precision (as a template parameter).
Top | Discussion index | About this forum | D home