Datetime to int

You cant since the time portion is float and it is truncated

So try using a float instead

the CAST as INT will return the integer in terms of days passed since the "date 0" (aka 1900-01-01)

so, integer cannot be used to refer to the time portion.
decimal could do that, but I wonder why you try to do this?

sorry it would be

print cast(Cast(convert(datetime, '12-Jan-2001 13:06:18') As float) * 24 * 3600 as BIGINT)

for greater precision use Numeric:

Print Cast(convert(datetime, '12-Jan-2001 14:06:15') As numeric(15,10))

or this

declare @myDate1 datetime = convert(datetime, '12-Jan-2001 13:06:15')
declare @myDate2 datetime = convert(datetime, '12-Jan-2001 13:06:16')

print cast(@mydate1 as bigint)*24*60*60 + datepart(hour,@mydate1)*3600 + datepart(minute,@mydate1)*60 + datepart(second,@mydate1)
print cast(@mydate2 as bigint)*24*60*60 + datepart(hour,@mydate2)*3600 + datepart(minute,@mydate2)*60 + datepart(second,@mydate2)

idea is calculate seconds passed for a given date

Try this instead

Convert datetime to int

here is what posted so far

declare @myDate1 datetime = convert(datetime, '12-Jan-2001 13:06:15')
declare @myDate2 datetime = convert(datetime, '12-Jan-2001 13:06:16')

Print cast(Cast(@mydate1 As float)*24*3600 as bigint)
Print cast(Cast(@mydate2 As float)*24*3600 as bigint)

print cast(@mydate1 as bigint)*24*60*60 + datepart(hour,@mydate1)*3600 + datepart(minute,@mydate1)*60 + datepart(second,@mydate1)
print cast(@mydate2 as bigint)*24*60*60 + datepart(hour,@mydate2)*3600 + datepart(minute,@mydate2)*60 + datepart(second,@mydate2)

print DATEDIFF(second, '1970/01/01 00:00:00', @mydate1)
print DATEDIFF(second, '1970/01/01 00:00:00', @mydate2)

3188293575
3188293576
3188379975
3188379976
979304775
979304776

Select allOpen in new window

missed KnightEknight

declare @myDate1 datetime = convert(datetime, '12-Jan-2001 13:06:15')
declare @myDate2 datetime = convert(datetime, '12-Jan-2001 13:06:16')

Print 'By deighton'
Print cast(Cast(@mydate1 As float)*24*3600 as bigint)
Print cast(Cast(@mydate2 As float)*24*3600 as bigint)

Print 'By Me :)'
print cast(@mydate1 as bigint)*24*60*60 + datepart(hour,@mydate1)*3600 + datepart(minute,@mydate1)*60 + datepart(second,@mydate1)
print cast(@mydate2 as bigint)*24*60*60 + datepart(hour,@mydate2)*3600 + datepart(minute,@mydate2)*60 + datepart(second,@mydate2)

Print 'By MistralolDate'
print DATEDIFF(second, '1970/01/01 00:00:00', @mydate1)
print DATEDIFF(second, '1970/01/01 00:00:00', @mydate2)

Print 'By knightEknight'
Print Cast(@mydate1 As numeric(15,10)) 
Print Cast(@mydate2 As numeric(15,10)) 

By deighton
3188293575
3188293576

By Me :)
3188379975
3188379976

By MistralolDate
979304775
979304776

By knightEknight
36901.5460069444
36901.5460185185

Select allOpen in new window

Which is stupidly complex compared to

SELECT DATEDIFF(second, '1970/01/01 00:00:00', GETDATE())

So if you are using a base time of 2000/01/01 00:00:00 then change it :)

If your using an int for a time then its going to be offset of a constant date from somewhere.
If its in seconds use the above if its in hours then switch our seconds for hours etc....

Without knowing more what the int represent it is actually impossible to answer the question

looks like you are new here: I did not like your sentence "stupidly complex"!

HainKurt simply summarized all of the suggestions in one post -- it wasn't a "stupidly complex" answer, it was a demo of all of the posted suggestions.

I don't really care if you didn't like it or not.

It is a simpler / cleaner solution based on the original poster's question based on the very limited information provider. I say let the original poster choose or provide more information as see what solution is selected :)

No one has criticized your suggestion, it is perfectly good.  It's your attitude that needs work.

Again, have a closer look at HainKurt's last summary post.  He's doing you a favor.

Mistralol, try putting 2050 into your formula!

We are edging closer to a glitch that I first heard about in the 1990s, I think it will hit by  2039, integer cannot hold the UNIX time, and of course many systems, such as financial stock systems work on dates 20+ years into the future.  

Also DateDiff cannot handle big differences with seconds, it blows up

Hi,
Thanks for the feedback, I will test the solutions and see, which works best for me.
The reason I am trying to do this is because I have one primary key field, lets call it 'ID'
The ID field has to be unique, I want to concatenate another field (code i.e. 'A') and the datetime value to make the record unique, I will then store the real date in another field. Only the ID field can be the primary key in this table, I didn't want to concatenate the actual datetime as this would be too long and messy:

CODE       DATETIME                           ID
A              12-Jan-2001 13:06:15        A_3188293575
A              12-Jan-2001 13:06:16        A_3188293576
B              12-Jan-2001 13:06:15        B_3188293575
B              12-Jan-2001 13:06:16        B_3188293576

It would be good if the ID field could be queried and the numeric equivalent suffix converted back to the original datetime.

Thanks

>>I don't really care if you didn't like it or not.<<
If you A) cannot produce a solution that satisfies the requirements of a SQL Server base date as opposed to a UNIX base date (1980 vs 1970) and B) are incapable of showing any manners than perhaps EE is not the right community for you, so you should do yourself a favor and go somewhere else.

hey I think Mistralol should be welcome to stay!  Everyone has their own way of saying things!  

sometimes I do make code complex, I've been doing it for 30 years and it might not seem complex to me -  but in this case it is for a reason, datediff seconds flunks for large spans of years.

It's when people send EMails to my boss attacking my code I start to feel a bit heated, but not here, lol.

Hey thanks for that :)

I was pissed at the fact that the different answers had been aggregated in a possible way to steal points etc..

The unix timestamp has almost nothing todo with things here. The only thing that makes a unix timestamp a unix timestamp is because its the number of seconds since the last epoch. It just happens to have the perfect way to convert a datetime to an int however :)

If your going to store a datetime as an int then sooner or later your going to overflow :) But it depends when you overflow based on when the base date is from (eg 1970 ... could just as easy be 2000 ...) this extends well past the year 2038. But the timestamp could also be measured in minutes or hours from a defined base date this would again greatly reduce the risk of overflowing so soon.

I was really leaving that part up to the OP to figure out exactly what he needed since there isn't enough information to a make a decent solution out of it. Not to mention that building something based on datetime to be unique is probably also a bad idea :)