I am also curious. A single example doesn't determine the proper conversion, but it seems plausible what you need is number of seconds since 1904-01-01 00:00:00.0 to store for correcting the 2 records you initially spoke of. It is straight forward this results from SELECT DATEDIFF(seconds,'19040101',@somedate) with @somedate being some date you want to "convert" to float. This just has the problem of DATEDIFF only generating differences within 32bit integer value range and for current dates that range is insufficient you get an overflow error.. To overcome that you would rather compute days since 1904-01-01 and multiply by 24*60*60.
For example
Code:
SELECT DATEDIFF(dd,'19040101','20171011')*24.0*60.0*60.0
results in 3590524800 and that would be the float number corresponding to today (11th October 2017) 0 am, if the assumptions about the root date and meaning of the float are correct. You could be more helpful here, Steve, by providing more examples and sharing what you finally did.
I know you are just IT/Management and no developer, but we just were3 at the step of you confirming that somehow, via the found root date, for example. Giving more examples, whatever. If you were unable to deduct you now need DATEDIFF or failed on that value range, you're always free to ask further. We usually don't answer all necessary steps covering all eventualities and branches irrelevant, if a certain step fails anyway. So I expected you to come back with further questions.
It's fine you made it, but it could have been less cumbersome, I think, if you would have continued the conversation.
I didn't blame you for the situation, I merely pointed out the fact this is unfortunate and asked, why none of the usual datetime types was used. We can't tell, this is not your design or your companies design, so this wasn't any accusation in the first place, merely a question. I also didn't expect the answer directly from you, but you should have contact to the developers of this or the vendor of the product, shouldn't you?
I don't know, maybe there is a simple reason for that, the choice of doing so, as a company was founded 1904 and this way of storing dates is its tribute to that fact. A bad idea to go off standards to use such a root, but that root might also come from any legacy software used. What matters is, the reasoning will reveal such a reference date to ensure the conversion correctness. You can't prove that from a single reference examples, especially as it turns out not even to adhere to the usual Unix Timestamp standard.
Bye, Olaf.