Nous enregistrons une date dans une table db SQLServer comme varchar. Lorsque cela est lu dans le code Java en tant que chaîne, puis analysé à une date, il est lu comme UTC (code Java est dans les serveurs qui sont en UT). Et reconvertissant la date à ET, il va 4 heures derrière. Comment gérer le stockage de la date ET dans cette colonne db il est lu comme ET dans le code java.
Nous recherchons autour des compensations, mais ne pas comprendre exactement ce qu'il faut faire.
Date varchar dans le tableau 29/03/2019 23:23:03 // nous voulons que cette date soit dans ET
SimpleDateFormat sdf = new SimpleDateFormat("MM/dd/yyyy HH:mm:ss");
Date beginDate = sdf.parse("03/29/2019 23:23:03");
// Le problème est lorsque ce code exécute, le serveur est en UTC. Alors beginDate // est lu comme 29/03/2019 23:23:03 UTC au lieu de 29/03/2019 23:23:03 ET
Attendu 29/03/2019 23:23:03 ET Actual 29/03/2019 23:23:03 UTC
Tout d' abord, vous devez être conscient qu'un Dateobjet n'a pas de fuseau horaire du tout . Il est juste un instant dans le temps. Donc , même si vous avez analysé correctement la valeur, il va représenter l'instant juste à temps, mais vous devrez peut - être le reconvertir en heure de l' Est plus tard.
Deuxièmement, vous devez être conscient que le stockage des valeurs telles que cette ambiguïté introduit - si vous stockez une valeur de (disons) 03/11/2019 01h30, heure locale que se produit deux fois - une fois avant la transition et une fois l' heure d' été après. Si vous êtes toujours le stockage fois dans le passé, vous devriez au moins envisager de stocker UTC au lieu - bien que ce n'est pas toujours la bonne réponse, et surtout pas si vous stockez des valeurs date / heure future .
Pour la partie analyse syntaxique, il vous suffit de définir le fuseau horaire dans le Calendarutilisée par SimpleDateFormat. Par exemple:
SimpleDateFormat sdf = new SimpleDateFormat("MM/dd/yyyy HH:mm:ss", Locale.US);
sdf.setTimeZone(TimeZone.getTimeZone("America/New_York");
Date beginDate = sdf.parse("03/29/2019 23:23:03");
Enfin, je fortement vous conseille de commencer la migration de votre code à utiliser java.timesi possible. Il est une API beaucoup plus agréable que de l' java.util.DateAPI , etc.