Centos 6 서버 콘솔에서 이 명령을 실행하면
# date
나는 이것을 받았다
Wed Oct 11 05:11:00 -03 2017
날짜가 -03(UTC 오프셋)을 반환하는 이유를 설명해 줄 수 있는 사람이 있나요?
이것 대신에
Tue Oct 10 12:30:50 AMST 2017
반품하려면 어떻게 해야 하나요?AMST숫자값이 아닌 값-03?
참고: 또한 이것을 실행하면
# zdump /etc/localtime
/etc/localtime Wed Oct 11 05:27:33 2017 -03
zdump: warning: zone "/etc/localtime" abbreviation "-03" lacks alphabetic at start
참고 2: UTC 오프셋을 사용하는 것은 많은 도구에서 예상치 못한 일이므로 이를 피하고 싶습니다. 이것이 가능합니까?
감사해요
답변1
tzdata는 최근 "발명된 약어" 사용을 중단한 것 같습니다.이에 대한 Red Hat의 보고서:
tzdata-2016b부터 새로운 시간대에 대한 tzdata 시간대 약어를 제공하는 새로운 방법이 구현되었습니다. 새 구역을 생성할 때 tzdata는 이제 새로운 약어(예: "ASTT")를 만드는 이전 명명 규칙 대신 숫자 시간대 약어(예: "+03")를 사용합니다.
또한, tzdata-2017a부터 공식적인 지위가 없고 편의를 위해 고안된 영역 약어를 제거하는 정책이 있습니다.
이러한 변경으로 인해 특정 tzdata-2016b 데이터 항목으로 인해 tzdata-2005j에서 tzdata-2015e 버전으로 파생된 zic 구현에서 경고가 발생할 수 있습니다. zdump 명령은 이러한 새로운 시간대에 대해 경고를 발행할 수도 있습니다.
이는 현재 보고 있는 동작과 정확히 일치하는 것 같습니다. 데비안 시스템에서도 같은 상황이 나타납니다.
$ zdump America/Sao_Paulo UTC
America/Sao_Paulo Wed Oct 11 11:19:19 2017 -03
zdump: warning: zone "America/Sao_Paulo" abbreviation "-03" lacks alphabetic at start
UTC Wed Oct 11 14:19:19 2017 UTC
오래된 버전의 tzdata를 실행하는 다양한 시스템에는 "BRT" 시간대가 표시됩니다.
$ zdump America/Sao_Paulo UTC
America/Sao_Paulo Wed Oct 11 11:19:40 2017 BRT
UTC Wed Oct 11 14:19:40 2017 UTC
두 경우 모두 실제 현지 시간이 정확한 것 같습니다. 문제는 여전히CentOS에서 인식됨.
가장 좋은 방법은 실수로 인한 구역 약어에 대해 걱정하지 않는 것 같습니다. 또는 이 문제에 정말로 관심이 있고 다른 시간대 업데이트에 관심이 없다면 tzdata 패키지를 2017a 이전 버전으로 롤백할 수 있습니다.