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?
