2010-10-21 31 views
1

Je me demandais si quelqu'un pouvait m'aider à comprendre pourquoi ces deux critères ne renvoyaient pas les mêmes ensembles de résultats. Pour moi, il semble étrange que SQL Server 2008 R2 ne sache pas utiliser le décalage tout en contraignant les données. Y a-t-il une meilleure manière de faire cela? Pour autant que je sache, le critère deux est le seul moyen d'obtenir les bonnes données.Utilisation de DateTimeOffset comme critère WHERE dans une requête SQL Server 2008

-- Criteria One 
OriginationDateTimeOffset >= TODATETIMEOFFSET('2010-10-20', '-08:00') AND 
OriginationDateTimeOffset < TODATETIMEOFFSET('2010-10-21', '-08:00') 

-- Criteria Two 
SWITCHOFFSET(OriginationDateTimeOffset, '-08:00') >= TODATETIMEOFFSET('2010-10-20', '-08:00') AND 
SWITCHOFFSET(OriginationDateTimeOffset, '-08:00') < TODATETIMEOFFSET('2010-10-21', '-08:00') 

Répondre

1

Pourquoi retournerait-il le même? Dans le critère 1, vous comparez l'heure d'origine au décalage, alors que dans le critère 2, vous modifiez le décalage sur les deux. TODATETIMEOFFSET convertit les valeurs en datetimeoffset

+0

Mais pourquoi devrais-je changer le décalage? Il y a déjà une compensation qui y est liée, donc, à mon avis, je devrais seulement établir le décalage des critères que je suis en train d'adopter et il devrait faire le reste. Il me semble que SQL Server devrait tout changer à 0 offset avant d'exécuter la requête. Pourquoi aurais-je besoin d'utiliser switchoffset pour mettre le décalage dans le même fuseau horaire que mon autre décalage. Cela semble redondant et inutile. –

0

SWITCHOFFSET change la valeur en un autre datetimeoffset. Par exemple:

DECLARE @OriginationDateTimeOffset DATETIMEOFFSET = '2010-10-20' 

SELECT @OriginationDateTimeOffset, 
    SWITCHOFFSET(@OriginationDateTimeOffset, '-08:00'), 
    TODATETIMEOFFSET(@OriginationDateTimeOffset, '-08:00') 

produit:

2010-10-20 00:00:00.0000000 +00:00 
2010-10-19 16:00:00.0000000 -08:00 
2010-10-20 00:00:00.0000000 -08:00 
+0

Oui, je connais la différence entre ceux-ci. J'essaie d'obtenir tous les dossiers qui se sont produits au cours de la première journée de la TVP, ce qui explique pourquoi je le donne aujourd'hui comme demain dans la TVP. Le problème est que SQL Server ne devrait-il pas savoir que les deux valeurs qu'il compare sont celles de DateTimeOffset et les convertir en UTC (offset 0) ou quelque chose de ce genre? Pourquoi devrais-je m'assurer qu'ils sont dans le même fuseau horaire si des informations de fuseau horaire sont liées aux deux données? –

+0

Je suis d'accord - Je ne comprends pas du tout l'utilisation de ce type de données. Certainement ne résout aucun des problèmes que j'avais avec le type "datetime2", en ce qui concerne le traitement de plusieurs fuseaux horaires. Sur cette base, je vous recommande de stocker une copie séparée en tant que datetime2 sans le décalage, et interroger cela. (beurk.) –