December 10, 2010
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
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
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
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