On Fri, 10 Dec 2010 15:14:11 -0500, Kagamin <s...@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
