網絡游戲服務器端對時間的需求可以說是無處不在的，小到技能的冷卻、技能的釋放時間、物品使用的冷卻、怪物的死亡重生、掉落物品的存在時間，大到節日活動的開啟、boss怪的精確出生、周任務日任務的准點開始等等。而這些對時間的需求都依賴於服務器端提供的時間服務的實現，因此時間服務、時間控制模塊在網游服務器端設計中是占有比較重要的地位。
本系列的第一篇《時間服務（一）序言》也描述了部分需求，但是用詞較為戲謔。本文將進一步細化需求，最大程度上把實際工作中對時間的需求描述清楚。
一、總體分類
按照大類來分，時間需求主要分為兩大類：相對時間需求和絕對時間需求。下面具體展開來說：
相對時間需求：
相對時間指的是時間間隔，反應在游戲里就是指從現在開始到未來某個時間點的時間間隔，比如從現在開始到以后的5s時間內。在游戲中，一些操作需要占用一段時間才能完成，比如采礦需要讀條，以及物品使用、技能吟唱、技能蓄力、上坐騎、跑步、飛行等等，這些操作有一些共同的特性：
1）當下的操作需要持續一段時間才能完成。
2）操作過程不需要存盤，如果玩家下線、掉線則該操作取消。不存在操作做到一半，player下線再上線能接着做的情況。
3）操作持續時間一般會很短，幾十毫秒到幾十秒不等。
4）持續一段時間才能完成主要出於幾個方面的考慮：客戶端播放動作、防止各種加速外掛、防止一些狀態切換太快影響游戲玩法（比如在戰斗的時候瞬間騎上馬逃跑，追殺的人死活追不上，可以類比戰斗類輕功的設計會有這方面的考慮）。
技能冷卻是不是也使用的相對時間呢？不是的，技能冷卻使用的是絕對時間（某年某月某日，某時某分某秒），可以想象這樣一個場景：玩家A在2月29日兩點使用了一個技能X，其中X的冷卻時間為一個小時，這個時候玩家A立即下線，那么使用相對時間表示冷卻時間就會出現兩種情況：如果這個相對時間不存盤，那么玩家A馬上再次上線則該技能又可以使用，這顯然是不能接受的；如果存盤，那么玩家A在一天以后再次上線，會發現技能還在冷卻，同樣是不能接受的。
跑步、飛行也需要使用時間服務？這是肯定的，因為在玩家發生位移時，移動過程（播放動作）是由客戶端發起，以固定的時間間隔向服務器發送當前的位置，服務器根據玩家的當前位置和上一個位置進行比較，並做對應的檢查，其中所需要的相對時間t主要用來檢查玩家是否超速。
相對時間模塊的設計一般會和游戲的心跳聯系在一起，因為心跳的固定間隔正好可以用來計算相對時間，游戲心跳設計參見《心跳設計》，該模塊的設計將在本系列的最后進行介紹，如果沒有特指相對時間，本系列所提到的時間服務時間控制都是指絕對時間。
絕對時間需求：
絕對時間指的是具體到公元紀年，比如某月某日零時，體現到計算機上則是距離1970.01.01的秒數，或者是tm結構。絕對時間在游戲中的需求也是無處不在的，特定節日活動的開啟、每日每周任務、固定時間段刷怪等等。本文剩下的小結將重點分析、細化絕對時間需求。
二、絕對時間需求分類
（1）時區需求
現在做游戲都希望能在海外市場分得一杯羹，因為內國市場日漸飽和，競爭也非常的激烈，每年新增的玩家數有限，而且大部分還被大企鵝瓜分了。這樣的條件下，海外市場是一個不錯的選擇，海外網游玩家往往付費能力很強，而且用戶粘性大，一個游戲可以堅持玩很多年（尤其是日本）。可謂“人傻錢多”，因此開發海外版本十分重要，對於服務器端來說，跨時區的問題就是在設計及編碼時需要考慮的問題。
時區問題實際上就是服務器端如何解析代表時間的整型值（time_t），並映射到對應的tm結構時具體代表的是哪一天的什么時候。比如：整型值1330675871，在北京時間（東八區）表示2012.3.2 16:11:11 星期五，但同樣的整型數值在夏威夷時間（西十區）表示2012.3.1 22:11:11 星期四。服務器在不同時區的地區，如何解釋這樣的時間整型值就是解決時區問題的關鍵。
服務器端如何解釋這些時間取決於策划，策划在編輯器上填了時間2012.3.2 16:11:11可以表達兩種意思。一種是指在所有時區里都是公元2012.3.2 16:11:11時執行某個操作，另一種意思是指全球同步操作，即在策划編輯數據的時區到達2012.3.2 16:11:11時，全球所有的服務器同時做某個操作。服務器端的時間服務模塊應該具備這兩種時區解釋的功能。
（2）時間段需求
時間段是時間服務中最基本的需求，比如在2012.03.01 10:00:00 ~ 2012.04.07 14:00:00期間開啟某個活動。
（3）時間重復需求
游戲里常用的時間重復一般出現在任務和活動里，比如每日、每周、每月、每小時的任務，或者還有可能出現每天幾點到幾點的活動等。
（4）時間項的任意組合
這項需求是比較變態的，比如《時間服務（一）序言》中提到的“2011年至2012年每個月的5號~14號之間，每天8點到15點之間的每小時里5分鍾到25分鍾的時間里，刷一些特殊怪，而且這一天必須是周五、周六或者周日”。時間項實際上是指年、月、日、時、分、秒、周七項數值，而實際使用中基本上不會精確到秒，因此主要是六項數值的組合。
時間項的任意組合包含了上訴（2）和（3）兩項需求。
三、總結：
時間服務在游戲中的使用是非常頻繁的，面對上訴需求應該用怎么樣一種統一的方式來表達所有的時間格式？在設計時間服務模塊時如何能做到簡潔方便的注冊服務、撤消服務、通知事件發生和回調處理等？這些都是設計者需要考慮的，同時也是本系列后續篇幅需要解決的。