• Kagamin <spam here.lot> Dec 10 2010
• "Steven Schveighoffer" <schveiguy yahoo.com> Dec 10 2010
• Kagamin <spam here.lot> Dec 12 2010
• Fawzi Mohamed <fawzi gmx.ch> Dec 10 2010

Kagamin <spam here.lot> writes:

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.

"Steven Schveighoffer" <schveiguy yahoo.com> writes:

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

Kagamin <spam here.lot> writes:

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

Fawzi Mohamed <fawzi gmx.ch> writes:

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.


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?