실행 중인 서비스의 동적 시간대

유일한 서비스 인스턴스는 처리 중인 데이터에 따라 시간대를 변경해야 합니다. 따라서 TZ각 데이터 등을 처리하기 전에 환경 변수를 변경할 수 있습니다.

TZ설정된 시간대 및 DST(일광 절약 시간) 값을 동적으로 변경하는 가장 좋은 방법은 무엇입니까? Olson 형식을 사용해야 할까요, 아니면 POSIX 형식을 사용해야 할까요? Olson 형식을 사용하고 DST를 끌 수 있나요?

다음 특성을 고려하십시오.

---

시간대 정보의 출처:

시간대를 감지하는 방식은 처리해야 하는 모든 정보에서 나옵니다. 즉, 다음과 같습니다.

• 절대 오프셋(UTC 기준)
• DST를 적용해야 하는지 여부를 나타내는 플래그입니다.이 플래그는 DST가 진행 중인지 여부를 나타내지 않고 현재 DST 설정이 적용되는지 여부만 나타냅니다.

한계:

• DST 플래그는 가능한 모든 시간대에 대해 DST 구성이 하나만 있다고 가정합니다. 그러나 서비스는 DST가 하나만 있는 시간대 집합으로 실행되어야 하지만,일부 시간대에는 일광 절약 시간이 적용되고 일부 시간대에는 그렇지 않습니다.
• 서비스는 TZPOSIX 형식에 따른 변수의 DST 설정을 인식하지 못합니다 Mm.w.d/time.

가능한 해결책:

서비스는 TZ다음과 같이 POSIX 형식으로 기본 시간대와 해당 DST(다른 모든 예상 시간대에 고유함)를 구성했을 것으로 예상할 수 있습니다.TZ=XXXST3XXXDT,M11.1.1/0,M3.1.1/0

서비스가 시간대를 변경해야 할 때마다 TZDST 플래그에서 요구하는 대로 원래 DST 설정을 지우거나 유지하여 오프셋을 조정하고 원래 변수를 변경합니다.

이 기본 시간대의 절대 오프셋 예를 고려하십시오 TZ=XXXST3XXXDT,M11.1.1/0,M3.1.1/0.

• tzoffset=5, dst=falseTZ=XXXST5
• tzoffset=5, dst=true:TZ=XXXST5XXXDT,M11.1.1/0,M3.1.1/0
• tzoffset=2, dst=true:TZ=XXXST2XXXDT,M11.1.1/0,M3.1.1/0

이 솔루션의 단점:

• 서비스는 자체 변수를 사용하여 TZ배타적(분리된) 사용자로 실행 되어야 합니다.또는 프로세스 및 해당 독점 변수를 시작하는 다른 방법.
• TZ서비스는 Olson 시간대 데이터베이스를 사용할 수 없습니다. DST 설정이 매년 변경되는 경우 시스템 환경은 중앙에서 업데이트되는 통합 Olson 데이터베이스를 사용할 수 없으며 매년 서비스에 대한 시간대 변수의 특정 구성(수동 또는 사용자 정의 업데이트)이 필요합니다. .
• 서비스에는 TZ절대 오프셋(UTC 기준) 또는 상대 기준(시간대 이름 기준)인지 여부에 관계없이 오프셋을 변경하는 방법을 알기 위해 새로운 구성이 필요합니다.