Trac 的版本玩法跟早期 Linux Kernel 的模式有點像，也就是版號偶數是正式版，奇數是開發版... 雖然現在 Linux Kernel 已經不玩這套了，但 Trac 還是維持這樣的開發方式。
先前一直都是用 Trac 1.0，其中 Due Date 的功能則是用「DateFieldPlugin」這個套件，讓 Trac 支援 date 格式，於是就可以在 [ticket-custom] 裡面指定 Due Date 了：
due_date = text due_date.date = true due_date.date_empty = false due_date.label = Due Date due_date.value = <now>
在套件的頁面也有提到在 Trac 1.1.1 後就有內建的方式可以用了：
Notice: This plugin is deprecated in Trac 1.2 and later. Custom fields of type time were added in Trac 1.1.1.
連結是連到 1.1 的，我要測 1.2 的，所以往現在的版本翻資料，可以看到在 TracTicketsCustomFields 這邊的說明：(這邊就懶的照原來 html 排了，用 pre 直接放縮排)
time: Date and time picker. (Since 1.1.1.)
label: Descriptive label.
value: Default date.
order: Sort order placement.
format: One of:
relative for relative dates.
date for absolute dates.
datetime for absolute date and time values.
這樣一來設定就會變成：
due_date = time due_date.format = date due_date.label = Due Date due_date.value = now
但底層資料怎麼存？先看 ticket_custom 這個表格的結構，可以看到是 EAV 的架構：
+--------+------------+------+-----+---------+-------+ | Field | Type | Null | Key | Default | Extra | +--------+------------+------+-----+---------+-------+ | ticket | int(11) | NO | PRI | NULL | | | name | mediumtext | NO | PRI | NULL | | | value | mediumtext | YES | | NULL | | +--------+------------+------+-----+---------+-------+ 3 rows in set (0.00 sec)
隨便拉一些可以看出來放法很簡單：
+--------+----------+------------+ | ticket | name | value | +--------+----------+------------+ | 1 | due_date | 2016-10-03 | +--------+----------+------------+
改成 Trac 1.2 內建的 time 後，塞 2018/02/28 變成：
+--------+----------+--------------------+ | ticket | name | value | +--------+----------+--------------------+ | 1 | due_date | 001519776000000000 | +--------+----------+--------------------+
拿掉後面的六個 0 後可以看到就是 2018/02/28 了，要注意的是，這邊會受到時區影響，我一開始測試的時候沒調整，寫進去的時間是用伺服器預設的時區計算的。另外也大概能理解前面放兩個 0 的目的，是為了讓 string 比較時的大小就會是數字實際的大小。
$ date --date=@1519776000 Wed Feb 28 00:00:00 UTC 2018
這樣就知道要怎麼做人工轉換了...