인터넷을 돌아다니던 중 재밌는 걸 찾았습니다. 우분투 파일 탐색기의 날짜 형식을 바꿀 방법을 찾던 중에 찾은 토론입니다. 아래는 대충 번역해본 건데 인내심 기르는 훈련을 하고 싶을 때 한번 찬찬히 읽어보시기 바랍니다. 컴퓨터 용어가 다소 나올 수 있으니 주의하세요.
본문
ekalfwonS
노틸러스(역자 주: 파일 탐색기 앱 이름)가 한 목록에서 혼합 형식 사용을 중지하고 일관된 형식으로 날짜를 표시하도록 하는 방법이 있습니까? 지금은 이렇게 보여줍니다:
11:10<br> 28 May 09:44<br> 1 Dec 2021 22:29
파일 목록과 관련 날짜를 보려고 하면 매우 헷갈립니다. 다음과 같이 날짜/시간을 볼 수 있기를 바랍니다. 예를 들면:
2022-06-11 11:10<br> 2022-05-28 09:44<br> 2021-12-01 22:29
antoniof
안녕하세요. 현재로서는 그렇게 할 방법이 없습니다.
어떤 상황에서 날짜 형식이 헷갈리시는지 여쭤봐도 될까요?
ekalfwonS
특히, 파일 목록을 보고 파일이 언제 생성되었는지 확인하고 싶을 때입니다. 일관된 형식을 읽는 게 편한데 다른 날짜 형식 세 가지를 번갈아가며 읽어야 하는 것이 매우 짜증납니다.
antoniof
그럼 헷갈리지 않고 그냥 짜증나는 거 아닌가요?
왜 3가지 형식을 읽어야 합니까? 각 파일에는 읽을 날짜가 하나만 있습니다.
ekalfwonS
실제 문제 대신 단어 뜻에 집중하고 있네요. 제가 게시한 내용을 다시 읽어보세요. 저는 "파일 목록을 볼 때"라고 말했습니다. 개별 파일이 아닙니다.
다른 날짜 형식 목록을 볼 때 날짜 목록을 비교하는 것은 헷갈립니다. 읽고 있는 내용을 해석하기 위해 각각을 다르게 파싱해야 합니다.
우분투의 다른 모든 곳에서 사용되는 날짜 형식을 설정할 수 있습니다. 노틸러스는 안 돼요. 왜죠?
antoniof
당신이 썼던 예를 들어 보겠습니다.
11:10<br> 28 May 09:44<br> 1 Dec 2021 22:29
여기서 문제가 정확히 무엇입니까? 첫 번째는 오늘 11시 10분, 두 번째는 17일 전, 세 번째는 6개월 전의 것이 분명합니다.
antoniof
다만 헷갈릴만한 상황이 있을 수는 있습니다. 이 경우는 그냥 버그일 수도 있으니 상황을 수정해야 합니다. 헷갈리는 예를 제공할 수 있습니까?
ekalfwonS
여기서 문제가 정확히 무엇입니까? 첫 번째는 오늘 11시 10분, 두 번째는 17일 전, 세 번째는 6개월 전의 것이 분명합니다.
문제는 이것을 더 빨리 읽을 수 있다는 것입니다.
2022-06-11 11:10<br> 2022-05-28 09:44<br> 2021-12-01 22:29
문제는 내가 이 형식을 원한다는 것입니다.
YYYY-MM-DD HH:MM
가장 큰 단위에서 가장 작은 단위로 가는 형식이 더 읽기 쉽기 때문입니다. 세 가지 다른 형식은 시간에서 분, 일 - 월 - 시 - 분, 일 - 월 - 년 - 시 - 분으로 이동합니다. 각각의 형식은 양쪽에 있는 더 작은 단위 사이에 더 큰 단위를 삽입하고 효율적인 파싱에서 날짜/시간을 읽기 어렵게 합니다.
antoniof
더 빠른 읽기는 상황에 따라 다르다고 생각합니다.
모든 날짜가 동일하게 보이면 어떤 형식이 가장 최근인지 한 눈에 알기 어렵기 때문에 원하는 형식을 읽는 속도가 느릴 수도 있습니다.
현재 형식을 사용하면 긴 날짜는 더 오래되고 짧은 날짜는 오늘에 더 가깝기 때문에 읽기 전에도 어떤 날짜가 더 최근인지 매우 빠르게 알 수 있습니다!
ekalfwonS
당신 말대로 더 빠른 읽기는 상황에 따라 다를 수 있습니다. 그러나 제 상황에서는 유사한 형식 목록을 읽는 것이 더 빠릅니다.
iOS, Windows 등과 마찬가지로 제가 지정한 날짜 형식을 사용하고 싶습니다. 로케일에서 짧은 날짜/시간 형식이 YYYY-MM-DD HH:MM이라고 표시되면 내 파일 브라우저에서 보고 싶습니다. Windows 및 기타 OS에서와 마찬가지로.
지금 하고 있는 일이 최적이라고 생각하는 것은 이해합니다. 하지만 사용자로서 제게는 최적이 아니라고 말씀드립니다. 그리고 이것은 이슈 트래킹 시스템에서 3년 동안 논의되었다는 사실에 근거할 때, 저는 혼자가 아니며 이 논의는 분명히 사라지지 않을 것입니다. 그러나 개발자는 여전히 사용자에게 듣는 대신 사용자가 잘못하고 있다고 말하는 데 대부분의 시간을 보내고 있습니다.
antoniof
저는 개발자 중 한 명이며 여기에서 여러분의 의견을 듣고 있습니다.
(프로의 팁: 원하는 대로 하도록 설득하려는 경우 온라인에서 누군가를 적대시하는 것은 좋은 전략이 아닙니다. :wink:)
그리고 더 듣고 싶어서 계속 질문을 해요.
경청하려는 제 노력에도 불구하고, 저는 아직 누구도 여기에 내재된 문제가 무엇인지 직접적이고 객관적인 방식으로 정확히 말하는 것을 듣지 못했습니다. 지금까지 제가 들은 것은 독선적인 선호도입니다.
그러나 실제 문제 정의를 놓치지 않도록 최선을 다해 귀를 기울일 것입니다.
알아내셨다면 주저하지 마시고 커뮤니티에 공유해 주세요! :slightly_smiling_face:
ekalfwonS
더 빠른 읽기는 상황에 따라 다르다고 생각합니다.
그렇다면 이것이 어떻게 독단적인 선호가 아닙니까? 노틸러스가 날짜를 표시할 때 사용자 경험을 개선하는 방식을 사용한다는 것을 보여주는 어떤 객관적인 데이터가 있습니까?
ekalfwonS
문제: 노틸러스에 표시된 날짜가 형식에 대한 로케일 설정을 따르지 않습니다.
문제: 노틸러스에 표시된 날짜를 사용자의 기대에 맞게 다시 형식을 지정할 수 없습니다.
문제: 노틸러스에 표시된 날짜가 ISO 8601을 따르도록 형식을 지정할 수 없습니다.
저는 당신이 이해할 수 있도록 이것을 설명하는 방법에 대해 일종의 근본적인 오해가 있는 것 같습니다. "그런데 왜 그렇게 하길 원하는 거죠?" 같은 말은 도움이 되지 않습니다. "왜 ISO 8601을 따르고 싶습니까?"라고 물을 수도 있습니다.
나는 정말로, 정말로, 당신이나 어떤 개발자를 적대시하려는 것이 아닙니다. 당신이 보고 있는 것은 밧줄 끝에 매달려서 노틸러스를 완전히 버릴 준비가 된 사용자입니다. 다.른. O.S.는. 제대로 합니다. 문제를 더 명확하게 만드는 데 필요한 문제 정의가 무엇인지 모르겠지만, 제가 원하는 목표와 이유가 지난 3년 동안 문제 로그에서 적어도 서너 번은 뭉개져 똑같은 결과를 낸 것 같습니다. 앞서 간 사람들을 대신하여 한 번 더 찔러봐야겠다고 생각했습니다.
antoniof
그렇다면 이것이 어떻게 독단적인 선호가 아닙니까?
독단적인 선호도를 갖는 것은 잘못된 것이 아닙니다. 개인 취향 때문에 옵션을 추가하지 않을 뿐입니다.
노틸러스가 사용자 경험을 개선하는 방식으로 날짜를 표시한다는 것을 보여주기 위해 어떤 객관적인 데이터가 있습니까?
경고: 이 질문은 양방향으로 작동합니다.
하지만 고집한다면 Google 드라이브는 파일 앱과 유사한 방식으로 시간을 표시합니다. 날짜 형식을 설정하는 옵션이 없습니다. 그리고 10억 명 이상의 활성 사용자를 보유하고 있습니다.
문제: 노틸러스에 표시된 날짜가 형식에 대한 로케일 설정을 따르지 않습니다.
그렇다면 해결책은 로케일을 따르는 것입니다. 더 많은 옵션을 추가하는 것이 아닙니다.
문제: 노틸러스에 표시된 날짜를 사용자의 기대에 맞게 다시 형식을 지정할 수 없습니다.
문제: 노틸러스에 표시된 날짜가 ISO 8601을 따르도록 형식을 지정할 수 없습니다.
당신은 2가지 사실을 진술했습니다. 아마도 이 두 가지 사실이 문제를 일으키는 것 같습니다. 그렇다면 이 두 가지 사실이 어떤 문제를 일으키는지 알고 싶습니다.
ekalfwonS
개인 취향 때문에 옵션을 추가하지 않을 뿐입니다.
요점은 현재의 "옵션"이 개인 취향의 결과라는 것입니다.
경고: 이 질문은 양방향으로 작동합니다.
예, 저는 당신한테 데이터를 요구하지 않았습니다. 프로그램이 작성되었을 때처럼 데이터 없이도 결정을 내릴 수 있다는 점을 지적한 것입니다.
Google 드라이브는 파일 앱과 유사한 방식으로 시간을 표시합니다.
그리고 Windows와 iOS 모두 제가 원하는 방식으로 설정할 수 있습니다. 활성 사용자 수는 모르지만 Google과 비빌만 할 겁니다.
그런 다음 해결책은 로케일을 따르는 것입니다. 더 많은 옵션을 추가하지 않습니다.
아! 이제 우리는 어딘가에 도달하고 있습니다. 그렇다면 노틸러스가 날짜 형식에 대한 로케일 설정을 확인하도록 요청하려면 어떻게 해야 할까요?
antoniof
요점은 현재의 "옵션"이 개인 취향의 결과라는 것입니다.
흠? 현재는 옵션이 없습니다!?
당신이 여기서 트롤링을 하고 있는지, 아니면 옵션이 무엇인지 오해하고 있는지 잘 모르겠습니다.
나중에도 이 단어를 쓴다고 가정하고 명확히 하겠습니다. 옵션은 사용자 인터페이스에서 사용자가 사용자 인터페이스에서 무언가를 변경할 수 있도록 하는 사용자 인터페이스의 컨트롤입니다. 예: "폴더를 파일보다 먼저 정렬"은 파일 앱에 있는 옵션입니다.
예, 저는 당신에게 데이터를 요구하지 않았습니다. 프로그램이 작성되었을 때처럼 데이터 없이도 결정을 내릴 수 있다는 점을 지적한 것입니다.
아, 알겠습니다. 실제로 모든 작은 결정에 대해 확실한 데이터를 얻는 것은 비현실적입니다.
그러나 그것은 우리가 어리석은 결정을 내려야 한다는 것을 의미하지는 않습니다. 정보에 입각한 결정을 내리는 데 사용할 수 있는 소프트 데이터 소스가 많이 있습니다.
- 사용자 피드백:
- 현재 스레드와 같이 사람들이 우리에게 직접 제공하는 피드백;
- 사람들이 소셜 네트워크와 댓글 섹션에서 말하는 것을 살펴봄으로써 간접적으로 피드백을 받습니다.
- 버그 보고서(및 보고서가 받는 좋아요 수);
- 기여자 피드백(기여자도 사용자이지만 문제와 더 넓은 의미에 대한 더 깊은 통찰력을 얻었습니다.)
- 디자이너 전문 지식(가장 신뢰할 수 있고 자격을 갖춘 출처, 다른 출처가 반대 방향을 가리키는 경우 그들의 결정에 이의를 제기할 수 있음)
- 유지보수 전문 지식
- 기술적 타당성(및 이를 구현할 시간을 찾는 사람)
- 유지 관리 부담(누군가가 그것을 구현했다고 해서 향후 몇 년 동안 반드시 우리가 유지 관리할 여유가 있지는 않음).
우리는 사용자 피드백을 많이 듣지만(심지어 인터넷에서 더 많은 피드백을 구함) 결정을 내리는 데 도움이 되는 다른 소스도 있습니다. 사용자의 말을 듣는다는 것은 가장 목소리가 큰 사용자가 요구하는 모든 것을 수행하는 것을 의미하지 않습니다.
antoniof
아! 이제 우리는 어딘가에 도달하고 있습니다. 그렇다면 노틸러스가 날짜 형식에 대한 로케일 설정을 확인하도록 요청하려면 어떻게 해야 할까요?
먼저 보이는 것이 실제로 로케일 설정을 따르지 않는지 확인해야 합니다.
예를 들어, Locale(예: HH:MM)을 따르는 동안 날짜 없이 시간을 표시할 수 있습니다. 로케일을 따라가면서 시간 없이 날짜만 표시하는 것도 가능합니다.
<details> <summary>(역자 주: 코드가 길어서 접음)</summary> <pre><code> [antonio@computer ~]$ locale -k LC_TIME abday="dom;seg;ter;qua;qui;sex;sáb" day="domingo;segunda;terça;quarta;quinta;sexta;sábado" abmon="jan;fev;mar;abr;mai;jun;jul;ago;set;out;nov;dez" mon="janeiro;fevereiro;março;abril;maio;junho;julho;agosto;setembro;outubro;novembro;dezembro" am_pm=";" d_t_fmt="%a %d %b %Y %T" d_fmt="%d/%m/%Y" t_fmt="%T" t_fmt_ampm="" era= era_year="" era_d_fmt="" alt_digits= era_d_t_fmt="" era_t_fmt="" time-era-num-entries=0 time-era-entries="d" week-ndays=7 week-1stday=19971130 week-1stweek=4 first_weekday=2 first_workday=2 cal_direction=1 timezone="" date_fmt="%a %d %b %Y %T %Z" time-codeset="UTF-8" alt_mon="janeiro;fevereiro;março;abril;maio;junho;julho;agosto;setembro;outubro;novembro;dezembro" ab_alt_mon="jan;fev;mar;abr;mai;jun;jul;ago;set;out;nov;dez" </code></pre> </details>다음 명령을 사용하여 현재 로케일 데이터를 확인할 수 있습니다.
locale -k LC_TIME참고로 여기 제 실행결과가 있습니다.
여기에서 볼 수 있듯이 로케일은 시간만, 날짜만, 날짜와 시간 모두, 날짜와 시간과 시간대 등을 표시하는 방법을 정의합니다. 로케일은 이러한 모든 형식을 정의하며 단일 형식을 요구하지 않습니다.
이때, 파일이 이러한 형식을 따르지 않을 수 있습니다. 이 경우 버그이므로 수정해야 합니다.
ekalfwonS
당신이 여기서 트롤링을 하고 있는지, 아니면 옵션이 무엇인지 오해하고 있는지 잘 모르겠습니다.
죄송합니다. 트롤링이 전혀 아니므로 용어 선택이 잘못되었을 수 있습니다. "현재 옵션"이란 "프로그램이 작성될 때 선택된 사항"을 의미했습니다. 프로그램이 작성되고 누군가가 날짜 표시를 위한 다양한 옵션 중에서 선택해야 할 때 프로그래밍된 옵션은 선택된 "옵션"이었습니다.
다음 명령을 사용하여 현재 로캘 데이터를 확인할 수 있습니다.
<details> <summary>(역자 주: 코드가 길어서 접음)</summary> <pre><code> rb4@Spectre:~$ locale -k LC_TIME abday="Sun;Mon;Tue;Wed;Thu;Fri;Sat" day="Sunday;Monday;Tuesday;Wednesday;Thursday;Friday;Saturday" abmon="Jan;Feb;Mar;Apr;May;Jun;Jul;Aug;Sep;Oct;Nov;Dec" mon="January;February;March;April;May;June;July;August;September;October;November;December" am_pm="AM;PM" d_t_fmt="%a %d %b %Y %r" d_fmt="%Y-%m-%d" t_fmt="%r" t_fmt_ampm="%I:%M:%S %p" era= era_year="" era_d_fmt="" alt_digits= era_d_t_fmt="" era_t_fmt="" time-era-num-entries=0 time-era-entries="S" week-ndays=7 week-1stday=19971130 week-1stweek=1 first_weekday=1 first_workday=2 cal_direction=1 timezone="" date_fmt="%a %d %b %Y %r %Z" time-codeset="UTF-8" alt_mon="January;February;March;April;May;June;July;August;September;October;November;December" ab_alt_mon="Jan;Feb;Mar;Apr;May;Jun;Jul;Aug;Sep;Oct;Nov;Dec" </code></pre> </details>여기 내 것이 있습니다.
antoniof
d_fmt="%Y-%m-%d"
로케일 제공 날짜(시간 없음) 형식입니다.
이 코드는 다음과 같이 변환됩니다.
2022-06-18
파일이 시스템에서 시간 없이 날짜를 표시하는 방식입니까? 그렇지 않은 경우 보고해야 하는 버그입니다.
antoniof
t_fmt="%r" t_fmt_ampm="%I:%M:%S %p"
로케일에서 제공하는 날짜 형식이 없는 초가 포함된 시간입니다. 불행하게도 로케일은 초가 없는 시간 형식을 정의하지 않습니다.
파일의 목록 보기에서 초를 표시하는 것은 바람직하지 않습니다. 우리의 사용 사례를 충족하는 로케일 정의 형식이 없습니다. 따라서 이 경우 파일 버그가 아닙니다. 단지 로케일이 충분히 포괄적이지 않습니다.
ekalfwonS
파일이 시스템에서 시간 없이 날짜를 표시하는 방식입니까? 그렇지 않은 경우 보고해야 하는 버그입니다.
왼쪽 열은 "수정됨"이고 오른쪽 열은 "수정됨 - 시간"입니다. 이에 대한 버그를 입력하게 되어 기쁩니다.
ekalfwonS
파일의 목록 보기에서 초를 표시하는 것은 바람직하지 않습니다. 사용 사례를 충족하는 로케일 정의 형식이 없습니다. 따라서 이 경우 파일 버그가 아닙니다. 단지 로케일이 충분히 포괄적이지 않습니다.
동의합니다. 초는 일반적으로 바람직하지 않습니다. 초를 알아야 하는 상황이 있었지만 거의 없었습니다. 그래도 시간 형식을 정의하는 로케일이 있고 파일이 이를 따른다면 사람들은 원하는 것을 가질 수 있습니다.
antoniof
이에 대한 버그를 입력하게 되어 기쁩니다.
해주세요, 고칠 수 있어요
ekalfwonS
버그 보고했습니다.
ekalfwonS
현재 형식을 사용하면 긴 날짜는 더 오래되고 짧은 날짜는 오늘에 더 가깝기 때문에 읽기 전에도 어떤 날짜가 더 최근인지 매우 빠르게 알 수 있습니다!
나는 이것이 사실이 아니라는 것을 깨달았습니다. "어제" 수행된 모든 작업은 "yesterday"를 추가하여 크기를 확장합니다. 따라서 오늘은 가장 짧고(시간만) 어제 한 일에 대해 크고, 그 다음에는 전날 일(요일/시간)에 대해 다시 작아지고 그 다음에는 (일/월/시간)이 됩니다.
antoniof
한 단어이므로 더 짧습니다.
너비를 픽셀 단위로 의미했다면 "더 좁게"라고 썼을 것입니다.
ekalfwonS
당신이 트롤링인지 농담인지 확실하지 않을 차례입니다.
- 시간은 한 단어로 쓰여지고, "Yesterday"는 (더 긴) 한 단어입니다. 그래서 단어 수는 오래되어도 늘어나지 않습니다.
- 뇌에서 시간을 분석하면 2~3단어(13:24, 11:20 등)로 읽히므로 오래될수록 시간이 짧아집니다.
"yesterday" 및 "mon"(오래될수록 더 짧은 단어)과 같은 단어를 사용하는 것을 제외하고 시간을 거슬러 올라갈수록 날짜 필드가 시각적으로 길어진다고 가정해 보겠습니다. 괜찮지만 도움이 되지 않습니다. 매번 전체 날짜를 읽고 싶습니다. 그것이 제가 파일 간에 날짜를 읽고 비교하는 방법이기 때문입니다. 날짜 읽는 법을 다시 배워야 한다고 말하는 것은 답이 안 됩니다.
antoniof
트롤링이나 농담이 아닙니다. 설명했듯이 더 좁다는 의미는 아닙니다.
영어 원어민이 아니기 때문에 잘못된 어휘를 사용하고 있는 것일 수 있습니다. 예를 들어 제가 의미하는 바를 설명하겠습니다.
- "yesterday"는 한 단어입니다.
- "24 May"은 두 단어입니다.
- "24 May 2017"은 세 단어입니다.
antoniof
날짜 읽는 법을 다시 배워야 한다고 말하는 것은 답이 안 됩니다.
저는 그런 말을 하지 않았습니다. 이제야 우리가 진전을 이루고 있으니 다시 적대감을 가지려 하지 마세요.
ekalfwonS
따라서 날짜와 시간을 직접 읽는 대신 이제 단어 수를 세어 제 파일이 얼마나 오래되었는지 알아야 합니까? 제게 맞는 국제적으로 인정된 날짜 형식을 가질 수 없는 이유는 무엇입니까?
antoniof
이제 제 파일이 얼마나 오래되었는지 알기 위해 단어 수를 세어야 합니까?
다시 말하지만 저는 그런 말을 하지 않았습니다. 가스라이팅을 멈춰주세요.
친절하게 예를 들었는데 지금은 함정에 빠진 기분이네요.
ekalfwonS
죄송합니다. 그럴 의도는 전혀 없었습니다. 제가 당신을 열받게 한다고 말하기 위해 유행어를 던지지 마세요. 제 북미 관점에서 평가할 때 둔감하거나 모순되는 진술로 계속 응답하기 때문에 여기에는 제가 이해하지 못하는 언어 또는 문화적 장벽이 있는 게 틀림없습니다.
당신은 점점 더 넓어지는 날짜가 파일이 날짜를 표시하는 방식의 특징이라고 말했습니다.
현재 형식을 사용하면 긴 날짜는 더 오래되고 짧은 날짜는 오늘에 더 가깝기 때문에 읽기 전에도 어떤 날짜가 더 최근인지 매우 빠르게 알 수 있습니다!
제가 당신이 더 길게 의미하는 것을 오해했을 때, 당신은 당신이 단어의 수를 의미한다고 명확히했습니다.
영어 원어민이 아니기 때문에 잘못된 어휘를 사용하고 있는 것일 수 있습니다. 예를 들어 제가 의미하는 바를 설명하겠습니다.
- "yesterday"는 한 단어입니다.
- "24 May"은 두 단어입니다.
- "24 May 2017"은 세 단어입니다.
그리고 나는 이제 당신이 의미하는 바를 이해합니다. "더 많은 단어는 과거의 날짜입니다." 이 말이 맞습니까?
antoniof
맞습니다. 제가 보는 방식을 설명하려고 노력했습니다. 저는 당신이 그것을 잘못보고 있다고 말하거나 그것을 보는 새로운 방법을 강요하지 않았습니다.
ekalfwonS
좋아요. 이제 "제 파일이 얼마나 오래되었는지 알기 위해 단어를 세어야 합니다"라는 제 의견이 어디에서 왔는지 알 수 있습니까?
저는 당신이 개인적으로 제가 뭔가 잘못하고 있다고 말하거나 새로운 패러다임을 강요하려고 하지 않는다는 것을 알고 있습니다. 그러나 소프트웨어는 그것을 간접적으로 알려줍니다. 형식으로 날짜를 읽는 옵션만 제공함으로써 프로그램은 "이것이 올바른 방법"이라고 말하고 있습니다. 로케일 설정을 따르지 않으면 지역 표준이나 개인 취향에 맞게 변경하여 해당 형식에 영향을 줄 수 없습니다.
저는 일반 신규 사용자가 "쉽게" 사용할 수 있도록 하는 데 전적으로 찬성합니다. 로케일 설정을 엄격히 따르면 필요한 경우 시간에서 초를 제거하더라도 그렇게 할 수 있습니다. 그리고 고급 사용자는 이미 수행하고 있는 로케일 설정을 조정하여 설정을 사용자 정의할 수 있습니다.
antoniof
이제 "제 파일이 얼마나 오래되었는지 알기 위해 단어를 세어야 합니다"라는 제 의견이 어디에서 왔는지 알 수 있습니까?
어디서 오는지 모르겠습니다. 단어를 셀 필요가 없습니다. 제 말을 더 잘 설명하기 위해 단어를 센 사람은 바로 저입니다.
그러나 소프트웨어는 그것을 간접적으로 알려줍니다. 형식으로 날짜를 읽는 옵션만 제공함으로써 프로그램은 "이것이 올바른 방법"이라고 말하고 있습니다. 로케일 설정을 따르지 않으면 지역 표준이나 개인 취향에 맞게 변경하여 해당 형식에 영향을 줄 수 없습니다.
죄송하지만 사실이 아닙니다. 이 프로그램은 무료 소프트웨어입니다. 무조건 지역 규범이나 개인 취향에 맞게 변경하여 해당 형식에 영향을 줄 수 있습니다.
따라서 실제로 이 소프트웨어가 어떤 식으로든 변경을 허용하지 않는다고 주장하는 것은 항상 잘못된 것입니다.
필요한 경우 시간에서 초를 제거하더라도 마찬가지입니다.
신뢰할 수 있는 방법으로 가능하다면 그렇게 할 것입니다.
하지만 불가능합니다. 로케일은 해당 용도를 제공하지 않습니다. 로케일 도구를 변경하고 모든 로케일을 업데이트하여 초가 없는 시간 형식을 제공해야 합니다.
ekalwonS
죄송하지만 사실이 아닙니다. 이 프로그램은 무료 소프트웨어입니다. 무조건 지역 규범이나 개인 취향에 맞게 변경하여 해당 형식에 영향을 줄 수 있습니다.
빌드 환경을 설정하고 제 자신의 코드 포크를 컴파일 및 디버그할 의향이 있다면 그렇습니다. 맞습니다.
언어 장벽 문제(단어 수 vs. 더 긴 문자열 vs. 등)에서 길을 잃고 다시 로케일에 대해 이야기하기 때문에 이 스레드를 지금 죽게 할 것입니다. 파일이 로케일 문자열을 따르지 않는다는 버그 보고서를 이미 발행했으므로 해당 버그 보고서를 고수하고 해결 방법을 지켜볼 것입니다.
감사해요!
ekalwonS
알겠습니다. 버그 보고서를 잠가 이 문제에 대한 논의를 중단하셨기 때문에 여기에서 논의를 계속해야 합니다.
안토니오, 파일이 로케일을 따르지 않으면 버그 보고서를 제출해야 한다고 말했습니다. 그래서 제출했습니다.
이 버그를 논의하면서 당신은 파일이 로케일을 따르지 않고 실제로 로케일을 따르지 않을 가능성이 있음을 인정했습니다. 로케일 설정에는 일반적으로 시간에 초가 포함되어 있고 이를 표시하고 싶지 않기 때문입니다. 제 로케일 설정에는 시간도 초가 없지만 충분하지 않았습니다.
이 문제를 해결할 방법이 없었는데 버그 보고서를 제출하라고 제안한 이유는 무엇입니까?
antoniof
당신의 사용자 정의 로케일은 매우 특이한 경우입니다. 따라서 이 버그 보고서를 위해 의도적으로 생성된 특이한 사용 사례는 무시해도 됩니다.
로케일 날짜 형식에는 초가 있습니다. 초가 없는 로케일 제공 시간 형식은 없습니다.
antoniof
알겠습니다. 버그 보고서를 잠가 이 문제에 대한 논의를 중단하셨기 때문에
거짓 비난.
전 어떤 토론도 중단하고 싶지 않습니다.
잔소리와 괴롭힘이 아닌 교양 있는 토론을 원하기 때문에 스팸을 차단해야 했습니다.
ekalfwonS
로케일 날짜 형식에는 초가 있습니다. 초가 없는 로케일 제공 시간 형식은 없습니다.
그렇다면 파일이 로케일 설정을 따르지 않는데 버그 보고서를 제출하라고 귀찮게 말한 이유는 무엇입니까?
ekalfwonS
교양 있는 토론을 원하기 때문에 스팸을 중지해야 했습니다.
제 목표는 과거에 비슷한 문제를 제기한 적이 있거나 알림을 받지 않고는 이 문제를 알지 못하는 더 많은 교양 있는 사람들을 토론에 참여시키는 것이었습니다.
antoniof
수정할 수 있는 날짜 형식의 버그가 있음을 보여주었기 때문입니다. 시간 형식은 할 수 없습니다.
antoniof
무엇을 위해 더 많은 사람들을 데려오나요? 대중의 압박?
ekalfwonS
수정할 수 있는 날짜 형식의 버그가 있음을 보여주었기 때문입니다. 시간 형식은 할 수 없습니다.
아! 지금은 이해. 설명해 주셔서 감사합니다.
ekalfwonS
무엇을 위해 더 많은 사람들을 데려오나요? 대중의 압박?
당연히 아니죠. 제가 적대적이 되려고 한다고 가정하지 마세요. 당신이 직접 말했습니다. 토론에 "좋아요"를 누르는 다른 사람들이 있으면 이 문제를 가진 게 한 사람 뿐이 아니므로 부분적으로 당신의 반응이 달라질 수 있다고요.
저는 우리가 맥주를 마시며 약 30분 만에 이 문제를 해결할 수 있었다고 생각합니다(역자 주: 이 대화는 5일간 이어졌음). 왜 이것이 계속 횡보하고 있는지 모르겠습니다.
3년이 걸렸지만, 파일이 ISO 형식의 날짜와 시간을 표시하지 않는다는 사실을 깨닫고 다른 애플리케이션으로 이동해야 합니다. 안타깝지만 솔직히 파일에 이 기능이 있어야 하는 이유를 설명하는 것보다 작업이 훨씬 덜 필요한 것 같습니다.
주석
중간중간 손에 땀을 쥐게 하는 구절들이 보입니다. 금방이라도 주먹이 나갈 것 같아요. 이 문제가 현피로 번지지 않은 이유는 영어에 존댓말과 반말의 구분이 없었기 때문일 것입니다.
번역은 구글의 도움을 받았습니다.
저도 ekalfwonS와 비슷한 의견입니다. GNOME 개발자들은 다들 꽉 막혀있는 걸까요? 참고로 제 컴퓨터에서는 날짜가 "16 3월 2020"처럼 뜹니다. 뭔가 단단히 잘못 되었다고 생각합니다. 저 같은 경우는 아마 로케일 설정을 바꾸면 해결될 거라고 생각하지만... 여전히 시간적 거리에 따라 표시형식은 달라지겠죠. 오늘 이 글로 GNOME의 입장은 잘 알았습니다. 자유 소프트웨어니까 이걸로 벌어먹는 분은 없겠죠? 과감히 버려도 되겠네요.