어제보다 오래된 항목에는 실제 날짜를 표시해야 한다

• 웹 UI의 상대 날짜 라벨은 사람 말처럼 보이지만, 실제 사용자가 날짜를 떠올리는 방식과 자주 어긋남
• 사람에게 “yesterday”는 오늘의 전날 0시~23시 59분이지, 단순히 “24시간 미만”이 아님
• 구현마다 기준이 달라지면 같은 서비스 안에서도 “yesterday” 표시가 흔들려 날짜 표시 신뢰도가 떨어짐
• “12 days ago”처럼 며칠 전을 숫자로만 길게 표시하는 방식은 사람이 자연스럽게 쓰는 시간 감각과 거리가 있음
• “last week/month/year”도 범위가 넓어 모호하므로, 어제보다 오래된 항목은 구체적인 날짜로 보여주는 편이 명확함

---

상대 날짜 라벨이 헷갈리는 이유

• “yesterday”, “2 days ago”, “a week ago” 같은 표현은 인간적인 시간 표현처럼 보이지만, 실제 날짜 판단에는 충분히 정확하지 않음
• 특히 “yesterday”는 사용자가 기대하는 의미가 분명함
  • 오늘의 전날을 뜻함
  • 전날 0시부터 23시 59분 사이를 가리킴
  • “24시간 미만”이라는 계산식과는 다름
• 컴퓨터 구현은 “yesterday”를 서로 다르게 계산할 수 있고, 같은 서비스 안에서도 표시가 달라지면 사용자는 날짜 정보를 덜 믿게 됨

오래된 항목은 날짜로 보여주는 편이 낫다

• “12 days ago” 같은 표현은 사람이 보통 생각하는 시간 단위와 잘 맞지 않음
• “last week”, “last month”, “last year”도 범위가 넓어 모호함이 남음
• 어제보다 오래된 항목에는 상대 표현 대신 특정 날짜를 표시하는 것이 더 읽기 쉽고 신뢰하기 쉬움

[cosine20]

진짜 깃헙도 그렇고 유튭도 그렇고 몇달전 몇년전 이런식으로 표기하는거 너무 싫습니다. 아래 HN 의견에도 있지만 1년 전이 실제론 1년 반 전인 경우도 있고 너무 애매해요.

[budlebee]

이거 참 공감이 되네요. 만드는 입장에서는, ㅇㅇ일전으로 표시하면 YY.MM.DD 로 할지 mmddyyyy 로 할지 등등 국가별로 다른 날짜표기법를 신경안써도 되긴 한데, 전 ㅇㅇ일전보다 날짜표기하는게 좋더라구요

[GN⁺]

Hacker News 의견들

• 특히 상대 시간 표시는 너무 부정확해짐
  YouTube에서 “1년 전”은 365일 전부터 729일 전까지 전부 될 수 있음
  “1년 전”으로 표시된 영상 두 개 중 어느 쪽이 더 최근인지 알려면, 실제로 영상을 열고 설명란까지 가서 날짜를 봐야 함

  • UI 디자이너들이 모여 사용자를 괴롭히는 GUI 미세공격 대회를 열었고, “N일 전” 트렌드가 우승해서 everywhere 퍼진 느낌임
    머릿속으로 날짜 계산하기 싫으니 그냥 정확한 타임스탬프를 보여주면 됨
    “1년 전” 같은 식으로 큰 범위의 정보를 버리지 말고 실제 시간을 보여줘야 함
  • 더 재밌는 건 사이트마다 반올림 기준이 다르다는 점임
    YouTube의 “1년 전”은 365~729일 전일 수 있지만, 어떤 사이트는 가장 가까운 연 단위로 183~548일 전을 뜻하고, 또 어떤 사이트는 11개월까지는 월 단위로 반올림하다가 350~548일 전을 “1년 전”으로 처리함
    또 다른 곳은 “지난 달력 연도 안” 같은 기준으로 1~365일 전부터 364~729일 전까지도 가능해짐
  • 지금이 2023년 10월인데, 2021년 11월에 올라온 영상이 “1년 전”이라고 나오면 안 되고 “거의 2년 전”이어야 함
  • 같은 날짜여도 시각이 늦으면 내림 처리됨
    2021년 10월 14일에 올라온 영상이 2년 전이어도, 그날 더 늦은 시각에 업로드됐으면 아직 1년 전이라고 표시될 수 있음
  • 첫 숫자가 1이 나오지 않게 하고 더 작은 단위로 바꾸면 부정확성을 줄일 수 있음
    예를 들어 120초 전까지, 120분 전까지, 48시간 전까지, 약 61일 전까지, 그다음 24개월 전까지 표시하는 식임
    목록 안의 상대 날짜는 대체로 참을 만하지만, 갱신되지 않는 문제가 훨씬 더 짜증 나며 “어제”까지만 제한한다고 해결되지는 않음

• 이걸 더 강하게 추천하고 싶음
  다행히 타임스탬프가 툴팁으로 보이는 경우가 많음
  예를 들어 npm 패키지 버전을 볼 때 “version 5.3.27 was released ‘about a year ago’” 같은 식으로 나오는데, 제정신인가 싶음
  오래된 패키지들의 출시 순서를 파악해서 호환 가능한 패키지 고정 조합을 짜려는데, 연속된 20개 패키지가 전부 “약 1년 전”으로 표시돼서 각각 툴팁을 열어 최근 버전인지 확인해야 함
  이런 식의 설계는 선을 넘었고, 불규칙 단수·복수 테이블명을 매핑하는 ORM을 만드는 사람들과 같은 부류로 보임

  • 정말 YouTube에도 툴팁이 있었음
    왜 몰랐는지 모르겠고 꽤 유용함
  • 제정신이 아닌 게 아니라 그냥 멍청하거나, 좋게 봐도 무능할 정도로 무지한 것임
  • 개발자용 도구에서 이런 짓을 하는 사람들은 범죄적 수준으로 무능함
    놀라운 건 그런 사람들이 아직 고용돼 있을 뿐 아니라, 이 멍청한 방식이 npm부터 GitHub, CircleCI까지 everywhere 퍼져 있다는 점임

• 더 나아가 이런 반올림된 상대 타임스탬프는 아예 없애고 싶음
  iOS Mail 앱이 특히 짜증 남
  열면 “방금 업데이트됨”이라고 나오는데, 당겨서 새로고침하면 2시간 전에 받은 읽지 않은 메일이 갑자기 나타남
  그냥 언제 업데이트했는지 정확한 시간을 보여주면 됨

  • 알림의 멍청한 타임스탬프는 더 나쁨
    한 시간 안에 못 보면 바로 부정확해져서 “1시간 전”인지 “2시간 전”인지밖에 안 보임
    어떤 알림이 정확히 언제 왔는지 꼭 알아야 할 수도 있는데 확인할 방법이 전혀 없음
    그냥 시간을 보여주면 되고, 시간은 내가 읽을 수 있음
  • Thunderbird의 장점 중 하나는 아직 정확한 날짜와 시간을 보여준다는 점임
    오늘이면 시간만 표시하고, 그 외에는 전체 날짜와 시간을 보여줌

• 절대 시간을 쓰면 브라우저가 사용자 선호 형식에 맞춰 표시할 수 있음
  https://developer.mozilla.org/en-US/docs/Web/HTML/Element/ti...

  • 서버는 데이터만 보내고 클라이언트가 표시 방식을 고르는 웹의 꿈은 완전히 죽었음
    웹 디자이너들은 사이트가 픽셀 단위까지 특정한 모양이 되길 원하고, 클라이언트 쪽 표시 제어는 그걸 방해함
    여전히 할 수는 있지만, 웹사이트가 그런 용도를 고려해 설계되거나 적극적으로 도와주지는 않을 것임
  • 평균적인 사용자가 실제로 보게 되는 모습이 어떤지 모르겠음
    예시에서 iOS/Safari 출력은 태그가 없는 것처럼 보임

• 흐릿한 날짜 표시에서 특히 불편한 건 요일이 가장 중요한 정보일 때임
  예를 들어 GitLab 기록을 볼 때 “지난주”나 “2일 전”보다 금요일에 병합됐는지 아는 게 훨씬 유용함
  채팅 기록도 월 경계 근처라면 대화가 월초 전인지 후인지가 중요할 수 있음
  그 외의 경우에도 개인적으로는 4주 전인지 2개월 전인지보다 정확한 날짜가 더 낫고, 정확한 날짜를 준다고 정보가 줄어드는 것도 아님
  흐릿한 날짜가 정확한 날짜보다 더 유용한 상황을 상상하기 어렵다

  • GitLab 팀 구성원임
    GitLab에서는 설정을 바꾸면 상대 시간 대신 절대 시간을 쓸 수 있음
    예: October 14, 2023 11:51AM
    https://docs.gitlab.com/ee/user/profile/preferences.html#sho...
  • Jira의 쓸모없는 시간 라벨을 요일 포함 전체 날짜로 바꾸는 Greasemonkey 스크립트를 만들었음
    자주 쓰는 브라우저 기반 소프트웨어에는 이런 걸 적용하는 걸 강력 추천함
  • 아주 특수한 경우에는 흐릿한 날짜가 유용할 수 있음
    다른 데이터베이스에서 정보를 가져와 재형식화해 사용자에게 보여주는 애플리케이션이 있는데, 갱신 비용이 크고 오래 걸려서 필요할 때 사용자가 수동으로 실행해야 함
    이 경우 마지막 갱신의 정확한 시각은 별로 중요하지 않고, 데이터가 얼마나 오래됐는지, 즉 원본과 어긋났을 가능성이 얼마나 되는지가 중요함
    어떤 정보는 몇 시간만 지나도 새로고침해야 하지만, 어떤 정보는 4~5일 이상 오래돼도 괜찮아서 최대 10분 걸리는 갱신을 할 필요가 없음
    이 목적에는 마지막 갱신 시각보다 대략적인 오래됨을 보여주는 편이 더 유용하고, 사용자가 현재 시각과 비교해 계산하지 않아도 됨
    다만 드문 사례이고 대부분은 상대적 흐릿한 날짜가 덜 유용함
  • 여러 시간대에 있는 사람들에게 가까운 미래의 시간을 전달할 때는 상대 시간이 유용함
    “이 댓글 이후 4~5시간쯤 뒤에 끝남”, “고쳐졌고 이 댓글 이후 약 15시간 뒤 다음 실행을 시작함” 같은 식임

• 타임스탬프를 잘못 보여주는 앱 중 내가 쓰는 최악은 gitg임
  이 스크린샷을 보면 됨
  https://ubunlog.com/wp-content/uploads/2018/06/git-gui-gitg....
  여러 커밋이 “3일 전”으로 표시되는데, 정보가 아예 없는 것보다 조금 나은 수준임
  오전인지 오후인지, 한 시간 안에 몰려 있었는지 하루 종일 퍼져 있었는지 알 수 없음
  고객사 작업 시간을 기록하지 못하고 일주일 뒤에 산정해야 할 때는 이런 정보가 중요해서, 커밋을 하나씩 클릭하고 화면 반대편의 타임스탬프를 확인해야 함

  • 스크린샷은 전체 날짜 표시가 항상 필요하다는 중요한 이유 중 하나임
  • Outlook 웹메일도 꽤 나쁨
    “며칠 전” 표시를 할 뿐 아니라, 자기가 중요하다고 판단한 항목을 맨 위에 보여주려 함
    그래서 일부가 중복된 두 목록이 뒤섞여 나오고, 끔찍함이 두 배가 됨
  • git 타임스탬프는 각 개발자의 로컬 시간대에 맞춰지고 검증되지 않아서, 전 세계 개발에서는 더 어려워질 수 있음
    https://alesnosek.com/blog/2017/01/02/git-getting-the-timing...
  • gitg에서 항상 전체 날짜·시간을 표시하도록 설정하는 방법이 없어 보인다는 게 놀라움
  • 스크린샷의 표시 방식은 업계 규제 기관이 있었다면 전문 직무 위반 후보감임

• 둘 다 보여주면 됨
  “1시간 전 (15:47)”
  “지난주 (MON 12 SEP 9:20)”
  “2년 전 (WED 14 APR 2021 11:47)”
  날짜 형식은 취향대로 하면 됨

  • 프런트엔드에서는 페이지에는 상대 시간을 렌더링하고, 툴팁에는 실제 타임스탬프나 날짜 형식을 넣는 방식이 유용했음
    더 자세히 보고 싶은 사람은 상대 날짜 위에 마우스를 올리면 됨
  • 예전에는 “필요한 사용자는 UI를 과부하시키지 않고도 찾을 수 있다”고 생각해 정확한 시간·날짜 정보를 툴팁에 넣었음
    몇 년 뒤 사용자 인터뷰에서 하이퍼링크식 밑줄만으로는 사용자가 “여기에 마우스를 올려야겠다”고 생각하지 않는다는 게 드러나 많이 되돌렸음
    이모지와 고해상도 디스플레이가 흔해진 지금은, 거슬리는 물음표나 돋보기 이미지로 툴팁 힌트를 주면 나이가 많거나 덜 숙련된 사용자에게 충분할지 궁금함
  • 그냥 날짜만 보여주면 안 되는 이유가 뭔가?

• 연도도 포함해야 함
  웹 포럼이 댓글 날짜를 “5 Jul”처럼만 보여줘서 나중에야 그 댓글이 몇 년 전 글이었다는 걸 알아차린 적이 너무 많음
  이제는 연도 없는 날짜를 더는 믿지 않고, 처음부터 안 보이면 연도를 어떻게든 찾게 됨

  • 연도는 4자리를 써야 함
    일주일에 몇 번 가는 포럼이 있는데 20~30년 된 곳이라 날짜가 08/11/02, 09/03/04처럼 찍혀서 매우 헷갈림

• “1년 전”은 충분히 정확하지 않을 수 있지만 “11개월 전”은 대개 충분함
  이런 함수를 구현할 때는 1이라는 숫자를 피하는 편임
  “1주 전” 대신 “6일 전”이라고 표시하는 식임

• Google이나 web.archive.org 같은 곳에 보관되면, 라벨이 클라이언트 쪽에서 계산되지 않는 한 인덱싱 날짜 기준의 상대 시간이 될 수 있음
  아카이브에서는 JavaScript도 제대로 동작하지 않을 가능성이 큼
  또 날짜를 더 접근성 있게 표시하려면 time 태그와 datetime 속성을 쓰는 것도 고려할 만함
  https://developer.mozilla.org/en-US/docs/Web/HTML/Element/ti...
  아직 브라우저에서는 span 태그와 크게 다르지 않지만, 웹페이지를 미래 호환적으로 만들어서 나쁠 건 없음