Konwertowanie daty juliańskiej JDE na gregoriańską

Myślę, że bardziej wydajne jest używanie natywnej matematyki opartej na datach i czasie niż całe to przełączanie się tam iz powrotem na różne formaty łańcuchów, daty i liczb.

DECLARE @julian VARCHAR(6) = '111186';

SELECT DATEADD(YEAR, 
  100*CONVERT(INT, LEFT(@julian,1))
  +10*CONVERT(INT, SUBSTRING(@julian, 2,1))
  +CONVERT(INT, SUBSTRING(@julian,3,1)), 
 DATEADD(DAY, CONVERT(INT,SUBSTRING(@julian, 4, 3))-1, 
 0));

Wynik:

===================
2011-07-05 00:00:00

Zakładając, że te dane nie zmieniają się często, o wiele bardziej efektywne może być przechowywanie daty jako kolumny obliczonej (dlatego wybrałem datę bazową 0 zamiast jakiejś reprezentacji łańcuchowej, która powodowałaby problemy z determinizmem, uniemożliwiając utrwalenie i potencjalne indeksowanie kolumny).

CREATE TABLE dbo.JDEDates
(
    JDEDate VARCHAR(6),

    GregorianDate AS CONVERT(SMALLDATETIME, 
      DATEADD(YEAR, 
        100*CONVERT(INT, LEFT(RIGHT('0'+JDEDate,6),1))
        +10*CONVERT(INT, SUBSTRING(RIGHT('0'+JDEDate,6), 2,1))
        +CONVERT(INT, SUBSTRING(RIGHT('0'+JDEDate,6),3,1)), 
      DATEADD(DAY, CONVERT(INT, RIGHT(JDEDate, 3))-1, 
      0))
    ) PERSISTED
);

INSERT dbo.JDEDates(JDEDate) SELECT '111186';

SELECT JDEDate, GregorianDate FROM dbo.JDEDates;

Wyniki:

JDEDate GregorianDate
======= ===================
111186  2011-07-05 00:00:00

Nawet jeśli nie indeksujesz kolumny, nadal ukrywa to brzydkie obliczenia z dala od ciebie, ponieważ utrwalone płacisz tylko w czasie zapisu, ponieważ nie powoduje to wykonywania kosztownych operacji funkcjonalnych w czasie zapytania, gdy występuje odwołanie do tej kolumny ...