Primefaces日曆的時區處理到固定後端時區

在Web應用程序的用戶可以選擇被傳遞到日曆窗口小部件的timezone屬性的時區：Primefaces日曆的時區處理到固定後端時區

<p:calendar value="#{curValue}" timeZone="#{settingsBL.getTimeZoneIdSet()}" />

在輔助bean的交付日期被轉換爲服務器的時區（JBoss在我的CEST中）。後端需要與UTC一樣的日期和時間（並以UTC遞送）。因此，當我存儲日期時，我必須將CEST日期轉換爲UTC並保存它。如果日期是從後端傳遞的，那麼它就是UTC。我必須將其轉換爲系統默認值（帶有CEST的JBoss），日曆會小心地在客戶端上正確顯示。這是正確的嗎？我對此有點困惑。服務器時區是可變的，不能很難設置爲UTC或其他。我的例子中，客戶端的日期總是轉換爲CEST。無論我在web.xml中設置爲javax.faces.DATETIMECONVERTER_DEFAULT_TIMEZONE_IS_SYSTEM_TIMEZONE。

我使用primefaces 5.2.13和2.2.12鑽嘴魚科與JBoss 6.4

來源

2015-10-09 opfau

這允許操縱所述時間部分的任何java.util.Date基於JSF組件的timeZone屬性必須設置爲預期由所述視圖中的一個（前端）。將java.util.Date實例從模型（後端）轉換爲String表示形式時將使用它，該表示形式將嵌入到生成的HTML輸出中。當將輸入的String請求參數值轉換爲將在模型中使用的具體java.util.Date實例時，它也將被使用。如果您不允許操作時間部分，則只需遵循timeZone="GMT"的默認設置。

現在來了關鍵：java.util.Date不是持有任何時區信息。它始終在格林威治時間。 JSF知道這一點。 JDBC知道這一點。 JPA知道這一點。只要您告訴JSF視圖使用什麼時區，並且您告訴JDBC/JPA數據庫使用什麼時區，那麼一切都會好的。

也許你的困惑是因爲你做了類似System.out.println(date)來驗證一個和其他。其toString()結果將在內部使用TimeZone#getDefault()，因此在String世代期間不明確使用GMT/UTC。然後，您會混淆地看到正在打印的系統默認時區中的date。要使用GMT時區打印date（以便調試/記錄/驗證它等），請執行以下操作：

System.out.println(DateTimeFormatter.ISO_DATE_TIME.format(date.toInstant().atZone(ZoneId.of("GMT"))));

來源

2015-10-09 12:57:05 BalusC

正確。在我的情況下，日期存儲在數據庫中沒有任何時區。按照慣例，UTC被存儲，當它被讀取時它也是UTC。所以也許我在這裏沒有問題？在我的情況下，當我在搜索掩碼中選擇一個月的第一個並提交時，該值是前一個月的最後一天。 – opfau

如果視圖不使用GMT/UTC時區，而是使用GMT + x中的某個時區，則確實會發生這種情況。這裏解釋：http://stackoverflow.com/questions/12351244/jsf-convertdatetime-renders-the-previous-day如果你節省了時間，它應該沒有問題，並且它被提交回來查看數據庫。或者更好的是，只要在需要呈現/接受/僅選擇日期（沒有時間）的組件中明確指定'timeZone =「GMT」''。沒有時間，你對**時間區不感興趣，對吧？ – BalusC

這是一個帶價值和價值的搜索。因此，從值的時間設置爲00:00:00，並將值設置爲23:59:59。因此，用戶只能選擇一個日期，但時間很重要。但是對於搜索字段的例子，我認爲UTC的硬設時區應該沒問題。提交之後更改日期的問題來自UTC到CEST的轉換，然後再轉換。我沒有解決問題......我很困惑。另一個調試會話的時間。 – opfau

Primefaces日曆的時區處理到固定後端時區

回答

相關問題