1，應用場景
時間類交易常見的場景有時間一致性(包括但不限於日切時間，商戶結算時間，收益結算時間)，對公節假日以及特殊日期，三方對賬，t+0/t+1日。
2，時間防資損的checklist
時間一致性
1.1 伺服器時間不一致
1.1.1 說明
伺服器時間不一致，各系統、與第三方系統和資料庫間的時間 不統一，導致交易落庫的時間記錄。
1.1.2 資損原因
各系統時間不一致，會產生某些系統認為無此交易或者交易失敗，但是底層系統是交易成功的，產生資損。
1.1.3 測試方法
修改伺服器或者資料庫時間，使兩者時間不一致，發起交易，檢查下游返回的交易結果是否可以正常處理並展示。
1.2 時間格式轉換不正確
1.2.1 說明
系統互動對於時間的精確度以及型別的傳遞，不同系統因使用時間型別不同，造成時間轉換精度缺失。
1.2.2 資損原因
系統間定義的時間格式不正確，或者轉換時錯誤，會導致交易的時間值為空或者為預設值，造成交易對賬失敗，導致充退。
1.2.3 測試方法
對系統間時間格式的轉換和型別著重關注，關注系統日誌報文，檢視傳遞值是否發生改變。上下游聯調。
1.3 日切時間點、收益時間點、商戶結算時間點、跨日交易
1.3.1 說明
交易隔日才翻轉為最終狀態，**公司對賬日切點、銀行交易日切時間點、商戶結算時間點。
1.3.2 資損原因
如果部分交易跨日才翻狀態，會影響資金份額的最終確認，造成資產方確認份額延遲，無法兌換預期收益。各系統進行對賬取的時間值範圍不一致（我方取值範圍為上乙個自然日，而第三方預設為上乙個排程結束至下乙個排程開始），導致交易核對有差異，出款或者結算金額不對，造成資損。
1.3.3 測試方法
對於理財的申購，對募集截止時間進行修改，交易狀態在募集結束後翻轉為成功的處理機制，各系統間對賬的交易時間範圍必須約定好，差異進行人工二次確認。若測試環境可行，模擬商戶之間結算，模擬不同的時間點。
特殊時間
閏年、理財成立日到賬日期、對公節假日
2.1 說明
閏年問題，對公節假日以及贖回天數的問題。
2.2 資損原因
理財產品類遇到閏年時，系統對使用者的收益計算會少，產生資損；和資產方確認贖回到賬日時，需考慮到理財成立日和到賬日期不能為對公假日（銀行系統對公假日不處理資金處理）。不同商戶商戶對公假日的對賬結算問題。
2.3 測試方法
將系統和資料庫日期改為閏年，計算使用者收益是否正確，對於自動生成理財產品的資產需調萬年曆將贖回到賬日為公假日的日期往後延遲。
不同時間字段取值
3.1 說明
上下游系統互動流程中有多個不同意義時間字段。
3.2 資損原因
一些使用者的交易有多個時間，建立時間，更新時間，下單時間，最終狀態時間，起息時間，到賬時間等值，上下游系統取值不對，造成提前給使用者回款，造成收益資損。
3.3 測試方法
對使用者的每個時間取值依次做檢查，尤其是收益、起息時間、回款時間、最終狀態時間。上下游系統取值保持一致，字段命名一致。
關注點1，伺服器時間一致性: 公司內部保持伺服器時間一致
2，時間格式一致性： 各系統時間保持一致
7，特殊日期： 不因特殊日期，造成時間出錯，引發資損。
8，對公節假日： 與第三方機構約定結算時間，遇到對公假日順延，不因對公假日造成資損。
9，不同時間字段取值： 上下游系統對日期字段命名保持一致，獲取字段相同
資損防控體系介紹
隨著有讚支付體量的增大，資產部門承擔的資金管理，風險把控的責任也越大。我們一方面要小步快跑，快速支撐業務，又要穩住底盤，守好底線。支付業務底線就是守護使用者的每一分錢，不能有資金損失。在我們搭建這套體系前，有讚支付資金類的線上監控是個盲區，缺乏自我發現的能力。業務成功了，但內部對使用者的資金操作可能...
資損防控體系介紹
隨著有讚支付體量的增大，資產部門承擔的資金管理，風險把控的責任也越大。我們一方面要小步快跑，快速支撐業務，又要穩住底盤，守好底線。支付業務底線就是守護使用者的每一分錢，不能有資金損失。在我們搭建這套體系前，有讚支付資金類的線上監控是個盲區，缺乏自我發現的能力。業務成功了，但內部對使用者的資金操作可能...
DB2時間函式
獲取當前日期 select current date from sysibm.sysdummy1 values current date 獲取當前日期 select current time from sysibm.sysdummy1 values current time 獲取當前時間戳 sele...