Migration de serveur local pour Azure: le FUSEAU horaire UTC. Comment le résoudre?

J'ai conçu ma demande, compte tenu du fait que, selon le cahier des charges,
doit s'exécuter sur un serveur situé en Italie et les clients seront en italien.

Il y a un mois, mon bos a décidé de tout mettre sur Azure.

Tout s'est bien passé. La seule chose qui me donne un certain problème est le fait que le serveur de temps est l'heure UTC.

Les solutions sont:

A) simple

modifier un script de démarrage du serveur de temps (
http://netindonesia.net/blogs/wely/archive/2011/06/26/setting-timezone-in-windows-azure.aspx
)

B) plus laborieuse

Changement à faire toute demande d'utilisation de l'UTC et l'affichage de l'heure correctement converti en heure locale.

Si je vais pour la solution A mon doute, c'est que le fait que le serveur est configuré avec un autre fuseau horaire peut en quelque sorte de créer des conflits avec Azure.

C'est vrai?

L'Option A, semble assez simple bien que vous aurez à vous assurer qu'il fonctionne à l'heure d'été ou vous trouverez tout est une heure au cours de l'été. Quand j'ai eu le même problème que j'ai choisi d'aller avec l'option B, car alors je ne voudrais pas avoir de problèmes avec les gens à l'aide de l'application à l'étranger.
Pouvez-vous nous en dire un peu plus sur votre architecture. Est-il basé sur le web ou client windows, va-t-elle par le biais de web services, etc. Ensuite, nous devrions être en mesure de vous aider plus.
Tous les Windows Azure Vm sont en vertu de l'UTC, et à mon avis c'est une très bonne conception de la propriété du nuage. Allez pour pour B, vous ne le regretterez pas.

OriginalL'auteur Marco Staffoli | 2011-06-28

  1. 12

    J'ai demandé à MME de soutien.

    C'est la réponse:

    Changer le serveur de temps sur l'Azure Virtual Machines à l'aide d'une tâche de démarrage n'est pas recommandé, vous devriez plutôt utiliser des méthodes comme TimeZoneInfo.ConvertTimeFromUTCTime dans votre code.

    Donc je ne vais pas changer le fuseau horaire du serveur.
    En attente d'une réponse du support, je découvre que la SqlServer 2008 ont DateTimeOffset type de données qui est parfait!

    http://blogs.msdn.com/b/davidrickard/archive/2012/04/07/system-datetime-good-practices-and-common-pitfalls.aspx

    OriginalL'auteur Marco Staffoli

  2. 4

    Il y A quelques années j'ai commencé l'élaboration de l'ensemble de mes applications, par conséquent de gérer les dates à l'aide de l'UTC sur le client et le serveur et je n'ai pas regardé en arrière depuis.

    Ce que vous pensez de DateTime vs DateTimeOffset

    OriginalL'auteur Oliver Weichhold

  3. 2

    Il y a deux problèmes avec DateTime.Maintenant et DateTime.Aujourd'hui, sur un côté client et côté serveur.
    Lorsque vous passez objet DateTime de client d'Azur en son Genre est égal à Locale et il contient les informations de fuseau horaire.
    (10 juin 2011, 12:30 -7)

    Toutefois, lorsque vous l'enregistrez dans la base de données de la région de l'information est perdue. Par la suite, lors de la lecture de ce champ de la base de données qu'il crée DateTime avec un Utc région (10 juin 2011, 12:30, 0)

    Finalement, votre client lit le datetime de manière incorrecte.

    Il y a plusieurs options pour résoudre ce problème sur un côté client.

    1) Convertir DateTime pour DateTimeOffset paramètres de la Méthode, ainsi que dans la base de données. Cela permettra de garantir que votre région (c'est à dire PST) seront enregistrées dans db

    2) Utiliser DateTime.SpecifyKind(dateTime, DateTimeKind.Non spécifiée) - de cette façon, le genre de type DateTime est indéterminée et, par la suite enregistré dans la db.

    var timeNow = DateTime.SpecifyKind(DateTime.Now, DateTimeKind.Unspecified);
serviceClient.SaveTime(timeNow);
var dateTime = serviceClient.GetTime();

    Être prudent de faire appel de DateTime.Maintenant sur un serveur. Vous feriez mieux d'utiliser DateTime.UtcNow. Ce temps ne doit pas être utilisé pour les données de l'entreprise. Idéalement, vous avez besoin de revoir votre code et passer DateTime ou DateTimeOffset de la part du client.

    DateTime ne contiennent pas les informations de fuseau horaire.
    lorsque l'objet DateTime est désérialisé et la Nature est Locale, elle définit les nouvelles DateTime adapter à un nouveau fuseau horaire, tout en gardant le dossier de la différence entre les 2 fuseaux horaires.

    OriginalL'auteur Boris Lipschitz