Différence entre 2 dates en SQLite

Question

Comment obtenir la différence en jours entre 2 dates en SQLite ? J'ai déjà essayé quelque chose comme ceci :

SELECT Date('now') - DateCreated FROM Payment

Il renvoie 0 à chaque fois.

Answer 1

 SELECT julianday('now') - julianday(DateCreated) FROM Payment;

Answer 2

Différence en jours

Select Cast ((
    JulianDay(ToDate) - JulianDay(FromDate)
) As Integer)

Différence en heures

Select Cast ((
    JulianDay(ToDate) - JulianDay(FromDate)
) * 24 As Integer)

Différence en minutes

Select Cast ((
    JulianDay(ToDate) - JulianDay(FromDate)
) * 24 * 60 As Integer)

Différence en secondes

Select Cast ((
    JulianDay(ToDate) - JulianDay(FromDate)
) * 24 * 60 * 60 As Integer)

Answer 3

Les deux réponses fournissent des solutions un peu plus complexes, puisqu'elles doivent l'être. Disons que le paiement a été créé le January 6, 2013 . Et nous voulons connaître la différence entre cette date et aujourd'hui.

sqlite> SELECT julianday() - julianday('2013-01-06');
34.7978485878557 

La différence est de 34 jours. Nous pouvons utiliser julianday('now') pour une meilleure clarté. En d'autres termes, nous n'avons pas besoin de mettre date() ou datetime() en tant que paramètres pour julianday() fonction.

Answer 4

La documentation de SQLite est une excellente référence et l'application DateAndTimeFunctions est une bonne page à ajouter aux favoris.

Il est également utile de se rappeler qu'il est assez facile de jouer avec les requêtes avec l'utilitaire de ligne de commande sqlite :

sqlite> select julianday(datetime('now'));
2454788.09219907
sqlite> select datetime(julianday(datetime('now')));
2008-11-17 14:13:55

Answer 5

Cette réponse est un peu longue, et la documentation ne vous le dira pas (car elle suppose que vous stockez vos dates en tant que dates UTC dans la base de données), mais la réponse à cette question dépend largement du fuseau horaire dans lequel vos dates sont stockées. Vous n'utilisez pas non plus Date('now') mais utilisez le julianday() pour calculer les deux dates par rapport à une date commune, puis soustraire la différence de ces résultats l'un de l'autre.

Si vos dates sont stockées en UTC :

SELECT julianday('now') - julianday(DateCreated) FROM Payment;

C'est ce qu'offre la réponse la mieux classée, et c'est également dans la documentation . Ce n'est qu'une partie du tableau, et une réponse très simpliste, si vous voulez mon avis.

Si vos dates sont stockées en heure locale, l'utilisation du code ci-dessus rendra votre réponse MAUVAIS par le nombre d'heures de votre décalage GMT. Si, comme moi, vous vous trouvez dans l'est des États-Unis, où le décalage GMT est de -5, votre résultat sera majoré de 5 heures. Et si vous essayez de faire DateCreated se conformer à l'UTC car julianday('now') va à l'encontre d'une date GMT :

SELECT julianday('now') - julianday(DateCreated, 'utc') FROM Payment;

Il y a un bogue qui fait qu'il ajoutera une heure pour une DateCreated c'est-à-dire pendant l'heure d'été (mars-novembre). Supposons que "maintenant" soit à midi un jour sans heure d'été, et que vous ayez créé quelque chose en juin (pendant l'heure d'été) à midi, votre résultat donnera 1 heure d'écart, au lieu de 0 heure, pour la partie heures. Vous devriez écrire une fonction dans le code de votre application qui affiche le résultat pour modifier le résultat et soustraire une heure aux dates DST. C'est ce que j'ai fait, jusqu'à ce que je me rende compte qu'il y a une meilleure solution au problème que je rencontrais : SQLite vs. Oracle - Calcul des différences de date - heures

Au lieu de cela, comme on me l'a fait remarquer, pour les dates stockées en heure locale, il faut que les deux correspondent à l'heure locale :

SELECT julianday('now', 'localtime') - julianday(DateCreated) FROM Payment;

Ou ajouter 'Z' à l'heure locale :

julianday(datetime('now', 'localtime')||'Z') - julianday(CREATED_DATE||'Z')

Les deux semblent compenser et n'ajoutent pas l'heure supplémentaire pour les dates DST et font une soustraction directe - ainsi, un élément créé à midi un jour DST, lors d'une vérification à midi un jour non-DST, n'obtiendra pas une heure supplémentaire lors du calcul.

Et si je reconnais que la plupart des gens vous diront de ne pas stocker les dates en heure locale dans votre base de données, et de les stocker en UTC pour éviter ce problème, toutes les applications n'ont pas un public mondial, et tous les programmeurs ne veulent pas passer par la conversion de TOUTES les dates de leur système en UTC et inversement à chaque fois qu'ils font un GET ou SET dans la base de données et s'occuper de savoir si quelque chose est local ou en UTC.