macOS에서 date -d가 illegal option 오류를 낼 때: 오류 없이 시각이 어긋나는 경우까지 직접 시험한 결과
리눅스식 date -d 스크립트를 macOS에서 돌려 오류를 만났거나 오류 없이 시각이 이상한 독자가 원인을 가려내고 양쪽에서 같은 값을 내는 형태로 바꾸게 돕는다.
이 맥의 date 에는 -d 가 없다. 그래서 어제는 -v-1d, 에포크 초는 -r, 문자열 해석은 -j -f 로 바꾼다. 다만 -j -f 는 빠진 칸을 지금 시각으로 채우고, 끝의 Z 를 (KST 에서) UTC 로 읽지 않았으며, 없는 날짜를 다음 달로 넘긴다. 오류가 없어도 값이 틀릴 수 있다.
스크립트에서 date -d 를 쓰는 곳을 찾아 자정까지 명시한 형식과 왕복 검사가 있는 함수로 바꾸고, 리눅스와 맥에서 같은 입력의 에포크 초가 같은지 비교한다.
목차
한 줄 요약: 이 맥(26.6.2)의 date 에는 -d 가 없어 어제는 -v-1d, 에포크 초 변환은 -r 로 바꾸되, -j -f 는 빠진 칸을 지금 시각으로 채우고 끝의 Z 를 KST 에서 로컬로 읽었으므로 시각까지 명시한 형식을 쓴다.
리눅스에서 쓰던 date -d yesterday +%F 를 맥 터미널에 붙였더니 아래처럼 실패한다.
/bin/date: illegal option -- d
usage: date [-jnRu] [-I[date|hours|minutes|seconds|ns]] [-f input_fmt]
[ -z output_zone ] [-r filename|seconds] [-v[+|-]val[y|m|w|d|H|M|S]]
[[[[mm]dd]HH]MM[[cc]yy][.SS] | new_date] [+output_fmt]이 글은 무엇으로 바꾸면 되는지, 그리고 바꾼 뒤 오류 없이 값이 어긋나는 세 경우를 이 맥에서 직접 만들어 보인다. 같은 오류는 2007년 MacPorts 메일링 리스트 답글에 인용된 질문에도 그대로 남아 있다. 질문자는 DAY="$(date -d "-$1 day" +%F)" 로 며칠 전 폴더 이름을 만들려다 막혔다. 확인한 환경은 macOS 26.6.2 arm64의 /bin/date(shell_cmds-329, BSD 계열), Homebrew의 GNU gdate 9.11(coreutils), bash 3.2.57, python 3.14.7, 시간대 Asia/Seoul(KST)이다. 아래 값은 시험한 날(2026-10-17)과 KST 기준이다. GNU 쪽은 리눅스가 아니라 이 맥에 설치한 gdate 로 시험했다.
용어 몇 개. date 는 시각을 출력하거나 바꾸는 명령이다. 에포크 초는 1970-01-01 00:00 UTC 부터 센 초이고, UTC 는 시간대 보정이 없는 기준 시각이다. 종료 코드는 0이 정상, 그 밖은 실패다. 표의 숫자 1792162800 은 2026-10-17 00:00 KST 의 에포크 초다.
맥의 date 에는 -d 가 없고 대응 옵션이 따로 있다
이 맥의 man date 는 옛 버전에 -d (일광 절약 시간 플래그)와 -t 가 있었지만 이제 시간대 데이터가 자동으로 처리한다고 적는다. 현재는 GNU의 -d 문자열 자리에 들어갈 옵션이 없고, -d yesterday, -d '+1 day', -d @1700000000, -u -d 2026-10-17 네 가지 모두 위 usage 와 종료 코드 1 로 끝났다. --utc, --version, --iso-8601 같은 긴 옵션도 illegal option -- - 로 실패했다. 반대로 gdate -v-1d 와 gdate -j 도 invalid option 으로 종료 코드 1 이었으니, 두 date 는 서로의 옵션을 모른다.
같은 일을 하는 형태를 나란히 놓으면 이렇다. 모두 같은 날 시험했고 결과가 같았다.
| 하고 싶은 일 | GNU(gdate) |
이 맥의 /bin/date |
결과 |
|---|---|---|---|
| 어제 날짜 | -d yesterday +%F |
-v-1d +%F |
둘 다 2026-10-16 |
| 에포크 초 → 날짜 | -d @1700000000 +%F_%T |
-r 1700000000 +%F_%T |
둘 다 2023-11-15_07:13:20 |
| 문자열 → 에포크 초 | -d '2026-10-17 00:00:00' +%s |
-j -f '%Y-%m-%d %H:%M:%S' '2026-10-17 00:00:00' +%s |
둘 다 1792162800 |
에포크 초 줄에는 함정이 하나 있다. GNU에서 -r 은 파일 이름을 받으므로 gdate -r 1700000000 은 No such file or directory 로 종료 코드 1이었다. 같은 -r 이 맥에서는 초를 받는다. 맥의 man date 는 -r seconds 와 -r filename 을 둘 다 적는다.
문자열을 읽는 -j -f 는 빠진 칸을 지금 시각으로 채운다
세 번째 줄의 -j -f 에서 -j 는 시계를 바꾸지 않고 읽기만 하겠다는 뜻이고 -f 는 입력 형식을 직접 지정한다. 위 표에서는 시각까지 형식에 넣었다. 날짜만 넣으면 어떻게 될까.
date -j -f '%Y-%m-%d' 2026-10-17 +%T이 맥에서 첫 실행은 21:17:03, 2초 뒤 같은 명령은 21:17:05 였고 둘 다 종료 코드 0이었다. 시각이 실행한 순간의 시계에서 온 것이다. +%s 로 바꾸면 값이 1792239425 와 1792239427 로 2초 차이가 났다. 맥의 man date 도 -f 형식이 정하지 않은 날짜와 시각 칸은 현재 시각에서 가져온다고 적는다. 같은 입력에 gdate -d 2026-10-17 +%T 는 00:00:00 이었다.
시:분만 주는 경우에는 초가 섞인다. '%Y-%m-%d %H:%M' 형식으로 2026-10-17 09:30 을 읽으면 09:30:25, 2초 뒤 09:30:27 이 나왔고 gdate 는 09:30:00 이었다. 캐시 키나 파일 이름에 이 값을 쓰면 실행할 때마다 달라진다. 오류가 없으니 종료 코드로는 못 잡고, 대신 형식에 %H:%M:%S 와 00:00:00 까지 넣어 쓰면 두 date 가 같은 값을 냈다.
끝에 Z 가 붙은 UTC 문자열이 로컬로 읽힌다
API 응답의 2026-10-17T00:00:00Z 를 에포크 초로 바꾸는 흔한 경우를 시험했다. gdate -d 2026-10-17T00:00:00Z +%s 는 1792195200 이었다. 이 값이 UTC 자정이다. 맥에서 date -j -f '%Y-%m-%dT%H:%M:%SZ' 2026-10-17T00:00:00Z +%s 는 오류 없이 1792162800 을 냈다. KST 자정이고 UTC 자정보다 9시간 이르다. 형식 끝의 Z 가 글자로만 맞춰지고 시간대로는 쓰이지 않은 것으로 보인다. -u 를 붙인 date -u -j -f ... 는 1792195200 으로 GNU와 같았다. 이 글의 해석으로는 Z 를 받는 입력이면 맥에서는 -u 를 함께 써야 하고, 시험한 것은 시간대 KST 한 곳이다.
없는 날짜와 남는 글자는 오류가 아니다
GNU는 gdate -d 2026-02-30 +%F 에 invalid date 와 종료 코드 1을 냈다. 맥의 date -j -f '%Y-%m-%d' 2026-02-30 +%F 는 2026-03-02 를 종료 코드 0으로 냈다. 2월 30일이 3월 2일로 넘어간 것이다. 2026-10-17 extra 도 비슷하다. 맥은 Warning: Ignoring 6 extraneous characters in date string ( extra) 를 표준 오류로 찍고 2026-10-17 을 종료 코드 0으로 냈고, gdate 는 invalid date 와 종료 코드 1이었다. 경고가 있어도 종료 코드가 0이라 set -e 나 || 로는 걸러지지 않는다. 반대로 abc 와 2026-13-01 은 맥도 date: illegal time format 과 종료 코드 1 이었다. 월이 13이면 막히지만 2월 30일은 넘어가는 셈이다.
두 쪽에서 모두 도는 함수
이 맥에서 date --version 은 종료 코드 1이고 gdate --version 은 0이었다. 이 차이로 어느 쪽인지 가를 수 있다. 아래 함수는 같은 코드를 /bin/date 와 gdate 에 각각 돌린 것이다. 날짜 문자열을 에포크 초로 바꾸고 되돌려 본 날짜가 처음 입력과 같은지 확인해, 맥에서 넘어가는 날짜를 오류로 바꾼다.
D=${DATE_BIN:-date}
if "$D" --version >/dev/null 2>&1; then F=gnu; else F=bsd; fi
midnight_epoch() { # $1 = YYYY-MM-DD, 로컬 자정의 에포크 초
local e back
if [ $F = gnu ]; then
e=$("$D" -d "$1 00:00:00" +%s) || return 1
back=$("$D" -d "@$e" +%F)
else
e=$("$D" -j -f '%Y-%m-%d %H:%M:%S' "$1 00:00:00" +%s) || return 1
back=$("$D" -r "$e" +%F)
fi
[ "$back" = "$1" ] || { echo "invalid date: $1 (became $back)" >&2; return 1; }
echo "$e"
}
yesterday() { if [ $F = gnu ]; then "$D" -d yesterday +%F; else "$D" -v-1d +%F; fi; }시험 결과는 두 date 에서 2026-10-17 이 모두 1792162800, 2026-02-28 이 모두 1772204400 이었다. 2026-02-30 은 맥에서 invalid date: 2026-02-30 (became 2026-03-02), GNU에서 invalid date 로 둘 다 종료 코드 1이었다. 함수를 쓰지 않고 python3 로 int(datetime.strptime("2026-10-17", "%Y-%m-%d").timestamp()) 를 쓰면(python 3.14.7, 시간대 KST) 1792162800 이 나왔고, 2026-02-30 은 ValueError 로 실패했다. 시간대가 같다면 이 길도 같은 값을 냈다.
이 맥에서 되는 것과 시험하지 못한 것
리눅스 문서로 읽던 몇 가지는 이 맥의 date 에서 그대로 됐다. date +%s%N 은 1792239427534045000 처럼 나노초 자리를 냈고(GNU도 같은 자리 수), 맥의 man date 는 %N 이 GNU와 호환되는 비표준 확장이라고 적는다. date -I 는 2026-10-17, date -Iseconds 는 2026-10-17T21:17:07+09:00 이었다. 다만 --iso-8601 긴 옵션은 안 된다.
시험하지 못한 것도 분명하다. 리눅스와 GNU date 의 다른 버전, 다른 macOS 버전, zsh, BusyBox date, 일광 절약 시간이 있는 시간대, -v 의 달 경계 계산(-v+1m 이 31일에서 어떻게 넘어가는지)은 확인하지 않았다. 위 오류와 값은 모두 같은 스크립트를 두 번 실행했을 때 시각이 들어간 줄만 빼고 같았다. 위 함수 코드는 DATE_BIN 만 바꿔 두 date 에 그대로 돌려 볼 수 있다.
세 줄 요약
- 이 맥의 date 에는 -d 가 없으므로 어제는 -v-1d, 에포크 초 → 날짜는 -r, 문자열 해석은 -j -f 로 바꾼다.
- -j -f 는 빠진 칸을 지금 시각으로 채우고 끝의 Z 를 (KST 에서) 로컬로 읽었으며 2월 30일을 3월 2일로 넘기니, 오류가 없어도 값을 의심한다.
- 시각까지 형식에 넣고 왕복 검사를 하는 함수로 감싸 리눅스식과 맥식에서 같은 에포크 초가 나오는지 비교한다.