February 14, 2005 at 1:25 pm
If I am setting a a new database.
Would you advise to use julian dates a long side the calenda date in SQL server 2000. Is it better to have than not to have, for TSQL to perform better.
Would this ease all the hassle with date searching.
February 15, 2005 at 6:57 am
I would think you'd want to store the calendar date and compute the Julian date. I'm sure you can find a user-defined function (UDF) that'll do it. If you wanted, you could also store a "computed" column in your table that has a formula which calls the UDF.
February 16, 2005 at 12:39 am
Main idea of the julian dates to order by date and get the date differences.
but now those funtions are bulit in with sql server. so I would think that it is not necessary
My Blog:
February 16, 2005 at 10:43 am
..." built in with sql server"...
Where, could not find info on BOL
February 16, 2005 at 11:06 am
I think he meant that the ability to sort dates and get date differences is built-in, not the ability to convert to Julian dates. For what it's worth, WRT Julian dates no longer being necessary, many functional requirements still need the ability to do Julian dates, especially in the government and military realms...
February 16, 2005 at 11:30 am
How would you go about to do a join on Dates fields on differerent tables when there are different formats.
Do you build a conversion table, or reformat dates in a NEW table ???
I thought julian dates would make this easier in a database ?
February 16, 2005 at 12:10 pm
SQL provides the DateTime format. If you use that, there are no conversion issues. Otherwise, if you are storing dates in other formats, int, char, varchar, you can CAST those values as DateTime and then do your comparison. See DateTime, CAST, CONVERT, "date and time functions" in Books Online.
For what its worth, if you want to use Julian dates, I posted two conversion functions on this site some time ago to do exactly that. Here's the link -
Julian and Gregorian Conversion Functions
Steve
Viewing 7 posts - 1 through 6 (of 6 total)
You must be logged in to reply to this topic. Login to reply