2017-09-14 1 views
0

J'ai créé des extensions DateTime que j'ai besoin de tester. Afin de les tester, je dois être capable de simuler que l'instance DateTime représente différents fuseaux horaires autres que celui du serveur local créant l'instance.Instance DateTime provenant de TimeZone non local dans .NET

J'ai essayé ce qui suit ...

// 
// Create the new date to test. It will be in the timezone of the server it was created on (EST).  
    DateTime localDate   = new DateTime(2017, 11, 14, 12, 0, 0); 
// 
// Get the TimeZone for another locale 
    TimeZoneInfo newTimeZone = TimeZoneInfo.FindSystemTimeZoneById("Egypt Standard Time"); 
// 
// Convert the localDate into a DateTime instance as if created on a server located in 
// "Egypt Standard Time". - NOT WORKING 
    DateTime test    = TimeZoneInfo.ConvertTime(localDate, origTimeZone); 
// 
// run the test 
    Boolean result = test.ExtensionMethod() 

Mais ce que des résultats dans "test" étant un autre DateTime dans le TZ EST local. L'heure a changé pour refléter le temps en Egypte mais l'instance, lorsqu'elle est évaluée ... convertie "toUniversalTime" par exemple, convertit toujours comme s'il s'agissait d'un fuseau horaire EST.

Étant donné l'exemple précédent, ma variable "test" contiendra un DateTime du '2017-11-14 19:00:00'. Quand je l'ai converti en UTC j'étais HOPING pour un résultat de '2017-11-14 17:00:00'. Au lieu de cela, je reçois '2017-11-15 00:00:00.

Est-il possible d'instancier un DateTime à partir d'un fuseau horaire autre que celui du serveur local?

+0

Il y a une surcharge pour convertir un DateTime dans une zone spécifique à UTC. L'utilisation de l'UTC comme "fuseau horaire" de base est une bonne idée quand on est confronté à cela: il suffit de s'encombrer de temps pour l'entrée et la sortie et le noyau devrait fonctionner. –

+0

Bien que j'apprécie le commentaire, je reconnais et suis entièrement d'accord avec la pratique que vous décrivez ... ce n'est malheureusement pas ma situation. Ce que j'ai vraiment besoin de savoir, c'est si ce que je demande peut être fait. Si cela doit être fait est circonstancielle et j'ai des réunions mis en place pour en débattre avec l'équipe du projet ... encore une fois ... Merci pour les commentaires. –

+0

Avez-vous utilisé la mauvaise variable ici: TimeZoneInfo.ConvertTime (localDate, 'origTimeZone'); –

Répondre

1

DateTime n'inclut aucune information de fuseau horaire. ToUniversalTime utilisera toujours le fuseau horaire du système local pour effectuer la conversion en UTC. Appeler ToUniversalTime sur votre objet original localDate vous donnera la valeur que vous cherchez. '2017-11-14 12:00:00' sur une machine fonctionnant en EST sera convertie en '2017-11-14 17:00:00' (+5 heures).

Vous pouvez également vous intéresser à l'utilisation de la classe DateTimeOffset, qui vous permet d'inclure une valeur de décalage avec la date et l'heure. Cela permet à des opérations telles que ToUniversalTime de connaître le décalage et d'effectuer la conversion en conséquence, plutôt que de supposer le décalage du fuseau horaire local.

Exemple d'utilisation DateTimeOffset:

TimeZoneInfo origTimeZone = TimeZoneInfo.FindSystemTimeZoneById("Eastern Standard Time"); 
DateTimeOffset localDate = new DateTimeOffset(2017, 11, 14, 12, 0, 0, origTimeZone.BaseUtcOffset); 

Console.WriteLine(localDate); // 2017-11-14 12:00:00 (EST) 

TimeZoneInfo newTimeZone = TimeZoneInfo.FindSystemTimeZoneById("Egypt Standard Time"); 
DateTimeOffset test = TimeZoneInfo.ConvertTime(localDate, newTimeZone); 

Console.WriteLine(test); // 2017-11-14 19:00:00 (EGST) 
Console.WriteLine(test.ToUniversalTime()); // 2017-11-14 17:00:00 (UTC) 

Sortie:

11/14/2017 12:00:00 PM -05:00 
11/14/2017 7:00:00 PM +02:00 
11/14/2017 5:00:00 PM +00:00