옵시디언 Bases 날짜·시간 마감: 정각 비교와 화면 갱신 확인하기

대표 이미지 설명: 정각 판정과 열린 화면의 갱신은 별개입니다. 실험 화면이 아닌 설명용 개념 삽화입니다.

‘오늘까지’가 아니라 ‘10시까지’인 일을 Bases에서 가려내려면 마감 속성을 날짜·시간형으로 준비하고, 마감 시각과 정확히 같을 때도 지연으로 볼지 먼저 정해야 합니다. 수식이 정각을 제대로 비교하는 것과 열어 둔 화면이 정각에 저절로 바뀌는 것도 별개입니다. 2026년 10월 8일 새 격리 볼트의 Obsidian Desktop 1.13.7, macOS 27.0, Asia/Seoul에서 확인한 결과, 엄격한 < 비교는 정각에 ‘미지연’이었고, 열린 화면은 실제 마감 후에도 한동안 그대로였습니다. 뷰를 다시 열자 ‘지연’으로 바뀌었습니다. 해당 환경의 한 번의 전경 관측이므로 일반적인 자동 갱신 간격이나 알림 기능을 보장하지 않습니다. 공식 속성 설명, Bases 함수, Bases 문법을 앱의 원본·화면 관측과 구분해 아래에 적었습니다.

날짜만 있는 마감과 시각까지 있는 마감은 어떻게 나누나요?

옵시디언 속성의 Date는 날짜만, Date & time은 날짜와 시각을 담습니다. 같은 이름의 속성에는 볼트 전체에 같은 타입이 적용됩니다. 기존 날짜형 키에 시각을 억지로 섞지 말고 새 키를 따로 쓰세요. 이번 격리 볼트에서는 due_day_control을 Date 대조군으로 두고, 시각 마감은 due_at_demo를 Date & time, 상태는 status_demo를 Text로 설정했습니다. 원본에는 due_at_demo: 2026-10-08T09:59:00처럼 날짜와 시각을 썼습니다. 공식 도움말의 예시 형식도 YYYY-MM-DDTHH:mm:ss입니다. 근거: 속성 유형과 YAML 형식

이 실험에서는 앱의 내부 metadataTypeManager.setType API로 속성 타입을 설정한 뒤 앱 화면과 .obsidian/types.json으로 확인했습니다. 속성 메뉴를 눌러 타입을 바꾸는 UI 절차를 실측한 것은 아닙니다. 독자는 공식 속성 유형 안내를 따라 자기 볼트의 타입을 확인하세요. 실제로는 처음 Text 타입으로 둔 ISO 형식 문자열도 isType("date")가 참이었습니다. 수식의 타입 검사만으로 ‘이 키는 Date & time 설정이고 시각 입력도 올바르다’고 판정하지 말고 속성 타입과 원본 값을 함께 보세요.

별도 DateOnly 대조군의 2026-10-08을 같은 날 10:00과 비교했을 때 앱은 ‘시각비교시 이전’으로 표시했습니다. 날짜만 있는 값을 오전 10시 마감처럼 다루면 의도하지 않은 지연이 생길 수 있습니다. 여기서는 날짜만 있는 마감 전체 사용법 대신 시각형을 다룹니다.

정각과 정확히 같은 마감은 지연인가요?

이 글의 업무 규칙은 ‘완료가 아니고, 마감 시각이 기준 시각보다 엄격하게 이전이면 지연’입니다. 따라서 due_at_demo < date("2026-10-08 10:00:00")에서 10:00:00과 같은 값은 미지연입니다. 정각부터 바로 지연으로 취급하고 싶다면 비교 연산자와 경계 사례를 업무 정책에 맞춰 바꿔 다시 시험해야 합니다. 옵시디언이 정해 주는 기본 업무 정책은 아닙니다. date()가 문자열을 날짜 객체로 만들고, <가 날짜 객체를 비교한다는 사실은 Bases 함수와 문법에 나옵니다.

실제로 사용한 Fixed.base의 핵심은 다음과 같습니다. TimeCases 폴더의 Markdown 노트만 넣고, 완료 처리→파싱 확인→시각 비교 순서로 평가했습니다. 작은 격리 볼트의 확인 자료이며 사용자 볼트에 바로 붙여서 성공을 보장하는 템플릿은 아닙니다.

filters:
  and:
    - file.inFolder("TimeCases")
    - file.ext == "md"
formulas:
  fixed_label: if(status_demo == "Done", "완료 제외", if(!due_at_demo.isType("date"), "시각 확인", if(due_at_demo < date("2026-10-08 10:00:00"), "지연", "미지연")))
  parsed_type: if(due_at_demo.isType("date"), "date", "not date")
views:
  - type: table
    name: 정각 대조
    order:
      - file.name
      - status_demo
      - due_at_demo
      - formula.parsed_type
      - formula.fixed_label

자기 볼트에서 재현할 때에는 TimeCases 폴더, due_at_demo/status_demo 키, Done 완료값, 기준 날짜·시간을 모두 실제 이름과 정책에 맞게 바꾸세요. 시각형 타입을 먼저 확인하고 비민감 테스트 노트로 시험하세요. 사례 A 원본은 다음과 같습니다. 실제 격리 볼트의 입력 원본이며, 다음 표는 같은 앱의 관측 결과입니다.

---
status_demo: Draft
due_at_demo: 2026-10-08T09:59:00
---

이 표는 고정된 가상의 ‘현재’ 시각을 앱에 주입한 것이 아니라, 실제 .base 수식의 기준을 10:00:00으로 고정한 결과입니다. 화면에는 TimeCases의 7개 결과가 보였고 별도 Other 폴더의 노트는 나오지 않았습니다. E·F·G는 ‘지연 아님’으로 묵살되지 않고 입력 확인 대상으로 남았습니다. 출력 열은 .base에 있는 계산식이며 노트 YAML에 결과가 저장된 것은 아닙니다.

실제 시간이 지나면 열린 화면도 바뀌나요?

이번에는 고정 기준식이 아닌 Live.base의 now()를 사용했습니다. 노트 LiveCases/L.md의 마감을 실제 준비 시각보다 약 2분 뒤인 2026년 10월 8일 06:46:27 KST로 두고 시계나 시간대를 모킹하지 않았습니다. 계산 열 clock_value: now()와 if(status_demo == "Done", "완료 제외", if(!due_at_demo.isType("date"), "시각 확인", if(due_at_demo < now(), "지연", "미지연")))를 함께 관찰했습니다. Bases의 now() 설명은 현재 순간의 날짜 객체를 반환한다고 하지만 열린 뷰가 정확히 언제 재계산되는지 보장하는 설명은 아닙니다.

마감 후 약 10초에 캡처한 열린 화면에서는 clock_value와 판정이 이전 값 그대로였습니다. 뷰를 다시 열자 둘 다 바뀌었습니다. 전후의 노트·.base 13개 원본 해시가 일치하며 이번 관측에서 원본이나 수식을 수정하지 않았습니다. ‘열린 뷰에서는 절대로 갱신되지 않는다’도, ‘재열기 없이 정각에 바뀐다’도 이 실험으로는 말할 수 없습니다.

내 볼트에서 결과가 다르면 어디부터 확인하나요?

먼저 원본 키와 속성 타입을 봅니다. due_at_demo가 Date & time인지, 노트의 값에 실제 시각이 있는지, 완료값이 Done과 정확히 일치하는지 확인하세요. isType("date")만 맞더라도 Text 속성의 ISO 값일 수 있습니다. 다음으로 필터 폴더와 확장자, 수식의 기준 시각과 </<= 정책을 확인합니다. 필터 범위 문제로 노트가 누락되거나 섞인다면 옵시디언 Bases의 폴더 필터 점검 안내를 참고하세요. 실시간 비교라면 앱 화면에 보이는 clock_value와 실제 시각을 나란히 기록한 뒤 뷰를 다시 열어 변화를 비교하세요. 화면만 믿고 마감 처리를 자동화하거나 알림을 기대하지 마세요.

이번 시험은 macOS·한국시간의 작은 별도 볼트 전경 실행만 다룹니다. 자정 경계, 다른 시간대·DST, 모바일, Sync, 백그라운드, 대형 볼트, 알림은 확인하지 않았습니다. 정각 판정 수식은 화면 갱신이나 알림을 수행하는 타이머가 아닙니다. 운영에 중요한 마감이라면 담당자가 별도 알림·확인 절차를 마련하고 해당 환경에서 시험해야 합니다.