Tag: date

64-bit time_t 的事情

看到「The perils of transition to 64-bit time_t (gentoo.org)」這篇，原文在「The perils of transition to 64-bit time_t」，Gentoo 的人在討論將 time_t 從 32-bit 換成 64-bit 遇到的困難。

這邊會想把 32-bit time_t 換到 64-bit time_t 的動力是 32-bit 的 time_t 會在 2038 年遇到 integer overflow，這是接下來的十幾年得想辦法的問題。

不過有意思的是 id=41684857 這邊提到了，當初 FreeBSD 在 porting amd64 時 (大約二十年前) 就直接把一堆變數換成 64-bit 了，其中也包括了 time_t，從第一天解決掉相容性的問題：

Every time I see people struggling with this, I am so incredibly glad that I forced the issue for FreeBSD when I did the initial amd64 port. I got to set the fundamental types in the ABI and decided to look forward rather than backward.

The amd64 architecture did have some interesting features that made this much easier than it might have been for other cpu architectures. One of which was the automatic cast of 32 bit function arguments to 64 bit during the function call. In most cases, if you passed a 32 bit time integer to a function expecting a 64 bit time_t, it Just Worked(TM) during the platform bringup. This meant that a lot of the work on the loose ends could be deferred.

We did have some other 64 bit platforms at the time, but they did not have a 64 bit time_t. FreeBSD/amd64 was the first in its family, back in 2003/2004/2005. If I remember correctly, sparc64 migrated to 64 bit time_t.

這算是個 Day 1 沒換就會有技術債包袱的問題 (遲早還是得換)，只是要討論哪種善後的方式是可以接受的。

Python 3.12 將淘汰 datetime.datetime 的 utcnow() 與 utcfromtimestamp()

在 Simon Willison 這邊看到「It's Time For A Change: datetime.utcnow() Is Now Deprecated」，引用的文章是「It's Time For A Change: datetime.utcnow() Is Now Deprecated」這篇。

文章裡面有提到歷史因素，以及這樣設計造成的問題。

在文章後面有提到替代方案，改了一下裡面的用法，等價於這個：

from datetime import datetime, timezone
datetime.now(timezone.utc)
datetime.fromtimestamp(timestamp, timezone.utc)

或是這樣：

import datetime
datetime.datetime.now(datetime.timezone.utc)
datetime.datetime.fromtimestamp(timestamp, datetime.timezone.utc)

要稍微注意一下這個歷史遺跡要被拆了... (StackOverflow 上面應該有很多用到這兩個 function 的解答)

月份傳回值 0 表示一月的考古

Hacker News 上看到「History of Zero-Based Months? (jefftk.com)」這篇，在考古為什麼常常看到 function 在傳回「月份」時是以 0 表示一月。從這篇提到的「Why is day of the month 1-indexed but the month is 0-indexed in C? (twitter.com/hillelogram)」則是 2020 年的討論。

在討論裡面有提到 hillelogram 的 tweet，裡面有個看起來算合理的考古過程...

試著用 Thread Reader 產生單頁 (讀起來會比較好讀)，但不知道為什麼一直失敗，結果往 Internet Archive 翻資料，倒是有 2020 年當初生成出來的版本。

另外還是列出原來第一則 tweet：

作者在研究這個題目的時候，馬上可以想到的是 C 語言裡面的月份就是 0-indexed，而其他程式語言都很有可能會是因為 C 語言的關係一路把這個特性繼承下去：

直接跳到最後面作者的猜測，他覺得可能是為了讓後續使用起來更方便的關係。

其他的欄位大多都是透過類似 sprintf("%d") 的方式直接輸出數字，所以用 1-indexed 讓人直接讀，而月份則會透過 array 來轉字串，所以用 0-indexes 讓程式轉：

So that's my best guess: the programmers were working with constrained resources and could optimize `asctime` tricky pointer arithmetic on the month and day-of-week, so made them 0-indexed. Day-of-month is just for displaying to the user, so is 1-indexed.

沒辦法確定，但就是一種猜測，看起來還蠻... 合理... 的？

用 PostgreSQL 的 int4range 與 GiST

發現自己根本還不熟悉 PostgreSQL 的特性，寫一下記錄起來。

產品上常常會有 coupon 與 voucher 之類的設計，這時候通常都會設定 coupon 或 voucher 的有效期間，在 MySQL 的環境下可能會這樣設計：

CREATE TABLE coupon (
  id INT UNSIGNED PRIMARY KEY AUTO_INCREMENT,
  code VARCHAR(255) NOT NULL,
  started_at INT UNSIGNED NOT NULL,
  ended_at INT UNSIGNED NOT NULL
);

另外是設計 index 的部份，在產品推出夠久後，通常是過期的 coupon 或 voucher 會比目前還有效的多，而還沒生效的 coupon 與 voucher 通常都不多，所以會設計成對 ended_at 放一組 B-tree index：

CREATE INDEX ON t1 (ended_at);

這個設計不算差，不過用了一些假設。

如果不想要用這些假設，可以改用 Spatial 的資料型態去模擬並且加上 index (使用到 LineString Class)，這樣就直接對 a < x < b 這類查詢更有效率，不過缺點就是可讀性會比較差。

在 PostgreSQL 這邊就有更清晰的資料結構來處理這些事情，主要是有一般性的 int4range 與 int8range 以及時間類的 tsrange、tstzrange 與 daterange (參考「Range Types」這邊有更多資料型態)，所以會變成：

CREATE TABLE coupon (
  id INT GENERATED BY DEFAULT AS IDENTITY PRIMARY KEY,
  code VARCHAR NOT NULL,
  active_at INT4RANGE NOT NULL
);

然後用 GIST 建立 index：

CREATE INDEX ON t1 USING GIST(active_at);

後續的 query 語法就用 <@ 的語法：

SELECT COUNT(*) FROM coupon WHERE 10000 <@ active_at;

塞了 10M 筆資料後的 table 可以看到本來需要的時間是：

Time: 779.542 ms

變成：

Time: 5.510 ms

不過缺點就是 SQLite 沒支援這些資料型態，對於 test case 就一定得跑個 PostgreSQL 起來測...

RFC 3339 與 ISO 8601 用範例的比較

在 Hacker News 首頁上看到「RFC 3339 vs. ISO 8601 (ijmacd.github.io)」這個連結，原始網站是「RFC 3339 vs ISO 8601」。

兩個都是試著定義日期與時間的表達方式，其中 ISO 8601 是在 1988 年定義出來的，被廣泛應用在很多 spec 裡，但最大的問題就是 ISO 8601 沒辦法公開免費取得，這點在前幾個月也在 Hacker News 上被討論過：「ISO-8601 date format reference not publicly available (twitter.com/isostandards)」。

而 RFC 3339 是在 2002 年訂出來，其中一個目標就是試著解決 ISO 8601 不公開的問題 (沒講明就是了)：

This document includes an Internet profile of the ISO 8601 [ISO8601] standard for representation of dates and times using the Gregorian calendar.

這份 RFC 3339 與 ISO 8601 的比較可以讓設計 spec 的人可以看一下，在大多數的情況下，RFC 3339 應該是夠用的...

第一堂：Course overview + the shell

這個系列是從『MIT 的「The Missing Semester of Your CS Education」』這邊延伸出來的，這篇文章講第一堂課「Course overview + the shell」。

前面大概講一下這 11 堂各一個小時的課大概是什麼，後面就開始講 shell 下的操作了。

先講了一些基本指令 (date & echo)，然後提到了環境變數 $PATH，接著就講目錄結構與 ls，然後就順便提到 man 可以拿來查說明，接著是講 redirect 與 pipe 以及 root 權限的特殊性 (以及 sudo)。

在課程最後面的這個範例，你第一眼看不會想到是第一堂課就可以教完的東西，但的確是結合了上面提到的所有東西，可以細細品味一下：

$ echo 1 | sudo tee /sys/class/leds/input6::scrolllock/brightness

Trac 1.2 裡 datepicker 每個禮拜的第一天改成星期天

在 Trac 1.0 搭配舊的 DateFieldPlugin 時，預設每週的第一天會是星期一，但這個設定可以在 trac.ini 內用 first_day 參數調整，像是這樣：

[datefield]
format = ymd
separator = -
first_day = 0

但在 Trac 1.2 在 trac.ini 裡就沒有提供設定讓人調整了... 而由於 Trac 是用 jQuery UI 的 Datepicker，在這個套件裡有提供方法讓人調整，所以解決的方向變成在 site.html 內用 JavaScript 處理，把這段程式碼塞到 JavaScript 的區段內就可以了：

// Datepicker
jQuery.datepicker.setDefaults({firstDay: 0});

一整個繼續惡搞中... 然後把 wiki 上的 Trac 條目也更新上去。

Trac 1.2 的 Due Date...

在先前的文章提到了把自己在用的事件管理系統 Trac 從 1.0 升級到 1.2，然後 Due Date 的設計改變了：「Trac 1.1 增加的 time 欄位，以及 Due Date 資料的轉移」、「總算把手上的 Trac 1.0 升級到 1.2 了...」。

Trac 1.2 的資料型態是在底層存 unix timestamp 的變形 (乘以 1000000，然後前端補上 0 存成文字)，這幾天用下來才發現一些以前沒遇到的問題。

一開始轉到 Trac 1.2 是設成 date，但意外的發現 (因為伺服器時間不是 UTC)，不同時區的使用者在更新 ticket 時，系統會判定 Due Date 有變動而產生變更記錄，想了一下就改用 datetime 來處理這個問題。

用了 datetime 一陣子後，才發現先前的公司遇到的情境中，時區差異都很小，所以不會有 Due Date 理解上的問題 (像是從 +7 到 +9 的時區)，如果今天是美國西岸跟台灣互相合作的話，只用 date 就會產生很明顯的理解問題了...

算是這陣子用 Trac 1.2 而對 Due Date 設計有不一樣的理解...

總算把手上的 Trac 1.0 升級到 1.2 了...

就如同上一篇提到的，Trac 在 1.1.1 後新增了 time 格式，所以本來的 DateFieldPlugin 有些資料要轉換。我這邊只有用在 Due Date，所以就是轉 due_date 的資料而已。

先把 due_date 都改成 due_date_bak：

UPDATE ticket_custom SET name = 'due_date_bak' WHERE name = 'due_date';

然後重新計算資料，這邊是因為所有的系統都是 UTC，所以直接轉就可以了：

INSERT INTO ticket_custom (ticket, name, value) SELECT ticket, 'due_date', LPAD(UNIX_TIMESTAMP(STR_TO_DATE(value, '%Y-%m-%d')) * 1000000, 18, '0') FROM ticket_custom WHERE name = 'due_date_bak';

而我的 Report 有用到 due_date 欄位的東西，本來是 c.value 直接輸出，現在要改成：

FROM_UNIXTIME(CONVERT(c.value / 1000000, UNSIGNED INTEGER), '%Y-%m-%d') AS due_date

Trac 1.2 相較於 1.0 最不習慣的地方應該是修改界面的位置改變了，現在 Add Comment 變成在 Modify 下面，有點不太習慣，但之後用久了應該就會習慣了。其他的修一修改一改都會動了...

Trac 1.1 增加的 time 欄位，以及 Due Date 資料的轉移

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

這樣就知道要怎麼做人工轉換了...