最近項目中實現了一個課程表的功能，核心功能如下：
1、需要記錄一周里每天每個時段的課程安排，后臺錄入
2、課程開始前，需要自動給課程關注者以各種提醒
于是采用了這樣的實現方案：
1、錄入時間只記錄當天的時分秒對應的毫秒數（這樣入庫的時間實際上是1970-01-01 HH:mm:ss）
2、定時任務根據當天所在的周數查詢當天的課程安排，并將課程時間換算成當天的時間（2015-09-08 HH:mm:ss），然后執行提醒的業務
很簡單的一個功能，但是因為時區問題出現了以下奇葩現象：
比如1970-01-01 10:00:00被最終換算成了1970-01-01 10:30:00
也就是說每一個入庫時間取出后都增加了不多不少半個小時
于是開始看java.util.Date源碼，一探究竟，發現有這樣一段：
BaseCalendar cal = getCalendarSystem(year);
if (tzoffset == -1) { // no time zone specified, have to use local
BaseCalendar.Date ldate = (BaseCalendar.Date) cal.newCalendarDate(TimeZone.getDefaultRef());
注意到TimeZone.getDefaultRef(),源碼如下：
public static TimeZone getDefault() {
return (TimeZone) getDefaultRef().clone();
}
/**
* Returns the reference to the default TimeZone object. This
* method doesn't create a clone.
*/
static TimeZone getDefaultRef() {
TimeZone defaultZone = defaultZoneTL.get();
if (defaultZone == null) {
defaultZone = defaultTimeZone;
if (defaultZone == null) {
// Need to initialize the default time zone.
defaultZone = setDefaultZone();
assert defaultZone != null;
}
}
// Don't clone here.
return defaultZone;
}
推測很有可能問題出在時區的選擇設置上，于是打印出來結果如下：
sun.util.calendar.ZoneInfo[id="Asia/Harbin",offset=28800000,dstSavings=0,useDaylight=false,transitions=19,lastRule=null]
果然如此，服務器時區錯誤，于是指出這個錯誤，讓運維修正的。
不過還是擔心運維層面帶來類似的錯誤，于是手動設置了時區：
TimeZone.setDefault(TimeZone.getTimeZone("Asia/Shanghai"));
logger.info("the default timezone info [{}]", TimeZone.getDefault());