2011-11-11 2 views
1

J'ai une table:DateTimes et .NET avec SQLite

CREATE TABLE [Lines] (
[Value] TEXT NOT NULL, 
[AddedOn] TIMESTAMP DEFAULT CURRENT_TIMESTAMP NULL 
) 

Comme vous pouvez le voir, la colonne AddedOn est un horodatage et est configuré pour enregistrer le courant datetime si l'on est pas prévu au moment de l'insertion.

S'il vous plaît considérer le code C# suivant:

using (var cmd = conn.CreateCommand())  
{ 
    cmd.CommandText = "INSERT INTO Lines(Value) VALUES (@Value)"; 
    cmd.Parameters.AddWithValue("@Value", objectValue); 
    cmd.ExecuteNonQuery(); 
}  

Notez que ci-dessus je laisse SQLite assigner la date. Maintenant, le même code, à l'exception que je passe la valeur AddedOn (par exemple DateTime.Now - en ce moment)

using (var cmd = conn.CreateCommand())  
{ 
    cmd.CommandText = "INSERT INTO Lines(Value, AddedOn) VALUES (@Value, @AddedOn)"; 
    cmd.Parameters.AddWithValue("@Value", objectValue); 
    cmd.Parameters.AddWithValue("@AddedOn", DateTime.Now); 

    cmd.ExecuteNonQuery(); 
} 

Si je puis compare les résultats de ces 2 inserts, je trouve que lorsque je laisse le coup par défaut AddedOn dans (premier exemple), il sauvegardait le datetime actuel au GMT. Lorsque j'ai passé la date explicitement (2ème exemple), il a enregistré le datetime actuel actuel dans mon fuseau horaire.

Est-ce intentionnel? Est-ce un bug? Il semble que le comportement devrait être cohérent et le datetime que je transmets devrait être converti en GMT.

Répondre

4

Est-ce un bug?

Je ne sais pas, mais je serais plus surpris si ce n'a pas atteindre votre objectif:

cmd.Parameters.AddWithValue("@AddedOn", DateTime.UtcNow); 

Pour moi, le comportement que vous rencontrez est logique.

Je ne m'imaginerais pas qu'une colonne TIMESTAMP aurait des informations sur si une heure devrait être en UTC ou non, et je ne m'attendrais certainement pas à forcer l'UTC par défaut. Cela permettra également une meilleure perf, car les conversions de fuseau horaire sont (relativement) coûteuses, et la conversion automatique serait un mécanisme caché.

+0

Je ne suis pas d'accord à propos de perf, car quand je récupère les données, je dois encore le convertir en un datetime local. – AngryHacker

+0

@AngryHacker: Si vous stockez dans un format et que vous récupérez dans un autre format, vous devez effectuer une conversion, de sorte que le hit de perf est inévitable. Cependant, la base de données ne force pas * un hit de perf sur vous, donc vous ne devrez pas subir deux conversions. Cela signifie que vous êtes libre de stocker l'heure locale si vous le souhaitez. –

+1

@AngryHacker: Votre question devient-elle alors: "Comment puis-je obtenir SqLite pour stocker' CURRENT_TIMESTAMP' dans l'heure locale "? Si oui, voir cette question: http://stackoverflow.com/questions/381371/sqlite-current-timestamp-is-in-gmt-not-the-timezone-of-the-machine - il y a deux ensembles de conseils ici Toujours utiliser UTC, et ne faire que la conversion sur présentation (ma recommandation personnelle) 2: Utiliser un mécanisme autre que CURRENT_TIMESTAMP (je ne le recommande pas car vous allez vous peindre dans un coin dans le futur. BEAUCOUP plus difficile et plus cher quand TZ et DST entrent en jeu au milieu). –