Par exemple, la requête suivante fonctionne très bien:comparaison datetime mysql
SELECT *
FROM quotes
WHERE expires_at <= '2010-10-15 10:00:00';
Mais cela effectue évidemment une comparaison « string » - Je me demandais s'il y avait une fonction intégrée pour MySQL qui fait spécifiquement « datetime » comparaisons.
... ce EFFECTUE évidemment une comparaison 'string'
Non - si le format de date/heure correspond au format pris en charge, MySQL effectue une conversion implicite pour convertir la valeur à un DATETIME , basé sur la colonne à laquelle il est comparé. Même chose se produit avec:
WHERE int_column = '1'
... où la valeur de chaîne de "1" est converti en un INTeger, car le type de données de int_column est INT, pas CHAR/VARCHAR/TEXT.
Si vous voulez convertir explicitement la chaîne à un DATETIME, la STR_TO_DATE function serait le meilleur choix:
WHERE expires_at <= STR_TO_DATE('2010-10-15 10:00:00', '%Y-%m-%d %H:%i:%s')
Mais cela effectue évidemment une comparaison
n ° « string » La chaîne sera automatiquement converti vers une valeur DATETIME.
Voir 11.2. Type Conversion in Expression Evaluation.
Lorsqu'un opérateur est utilisé avec opérandes de différents types, la conversion de type se produit pour rendre les opérandes compatibles. Certaines conversions se produisent implicitement. Par exemple, MySQL convertit automatiquement les nombres en chaînes si nécessaire, et vice versa.
Je sais que son joli vieux mais je rencontre juste le problème et il est ce que je voyais dans la SQL doc:
[Pour de meilleurs résultats lorsque vous utilisez BETWEEN avec des valeurs de date ou d'heure,] utilisez CAST() pour convertir explicitement les valeurs en type de données souhaité. Exemples: Si vous comparez une valeur DATETIME à deux valeurs DATE, convertissez les valeurs DATE en valeurs DATETIME. Si vous utilisez une constante de chaîne telle que '2001-1-1' dans une comparaison à un DATE, transtypez la chaîne en DATE.
Je suppose qu'il est préférable d'utiliser STR_TO_DATE depuis qu'ils ont pris le temps de faire une fonction juste pour cela et aussi le fait que je trouve cela dans le doc ... ENTRE
Si votre serveur ou les chaînes ne sont pas en UTC soyez prudent car la conversion implicite se produit avec le serveur/sessions time_zone pas le fuseau horaire de la valeur à laquelle il est comparé. Donc la chaîne est la même heure locale même si vous la comparez avec UTC_TIMESTAMP(). – ClearCrescendo
@ClearCrescendo: Bon point, merci. –