On May 9, 2:40*pm, Sonnich Jensen <sonnichjen...@gmail.com> wrote:
> On May 9, 8:47*pm, Peter Duniho <NpOeStPe...@NnOwSlPiAnMk.com> wrote:
>
>
>
> > On 5/9/11 8:57 AM, Sonnich Jensen wrote:
>
> > > Hi all
>
> > > I need a way to have a
>
> > > public List<double> *XValues = new List<double>();
>
> > > which also can hold DateTime values.
>
> > > How can I convert a double to DateTime and viseversa?
> > > I tried today, but did not find a proper way
>
> > It can be done, per the other two replies and even other techniques.
>
> > But I would advise against it. *If you are trying to store values of
> > type double and DateTime in the same data structure and yet have no
> > readily convenient way to convert between double and DateTime, then you
> > have a fundamental design error.
>
> > Instead of trying to store two completely unrelated types in the same
> > data structure, you should fix your design so that doing so isn't necessary.
>
> > If you would explain at a higher level what it is you're actually trying
> > to do, then we can assist you with that.
>
> > Pete
>
> Thanks to all of you.
>
> I found my solution in ToOADate() and a few additional functions.
> I have a database, where I have my dates in Deplhi format, and I guess
> that ToOADate() *and FromOADate() can be useful.
>
> From delphi help:
> Most VCL objects represent date and time values using the TDateTime
> type. The integral part of a TDateTime value is the number of days
> that have passed since 12/30/1899. The fractional part of a TDateTime
> value is fraction of a 24 hour day that has elapsed.
>
> Following are some examples of TDateTime values and their
> corresponding dates and times:
>
> 0 * * * 12/30/1899 12:00 am
> 2.75 * *1/1/1900 6:00 pm
> -1.25 * 12/29/1899 6:00 am
> 35065 * 1/1/1996 12:00 am
In the software world, it's generally considered bad form to rely on
the underlying implementation of the date storage. I.e., in general,
it's good not to violate the principle of encapsulation.
Nevertheless, Microsoft has violated that maxim in order to allow
programmers to skirt using something like a DateDiff function when
comparing dates in SQL queries. The chances are almost nil that
Microsoft is going to change the underlying representation of a date
value during this century, but purists would recommend not taking
advantage of the existing internal floating-point representation. I
generally use comparison functions that expect date formats when
comparing dates, but I'm one of those purists I mentioned :-). Even
operator overloading brings up the same issues. The floating point
precision, though, is not really an issue at all when simply comparing
dates, even when comparing to the second (about 0.00001157 of a day).
Mathematically, this is because a conversion to floating-point forms a
partially ordered set (poset) where the corresponding values are
isomorphic to the poset of date/time values (i.e., they maintain the
same relative order as the original date/time values even if the
conversion to number of days plus fraction of a day is not quite
exact). I recommend using the date format for dates and using date
comparisons, ignoring the internal representation. Even if Microsoft
decides to change the internal representation of dates, they will be
responsible for updating any date comparison functions at the same
time, and no changes to your code should be required. Of course, you
are free to determine your own risk comfort level and relaxed degree
of pedantry if adherence to conventional standards of programming is
too onerous in this situation.
James A. Fortune
(E-Mail Removed)
Similar Threads
