고급 도메인 모델 7 - 날짜 시간 처리

IT/mendix

고급 도메인 모델 7 - 날짜 시간 처리

가능성1g 2025. 7. 7. 13:48

소개

Adrian의 앱에 있는 경기정보에는 각 경기정보의 시작 날짜 및 시간에 대한 datetime 구성 요소가 있습니다.
경기 시간을 지키는 것은 매우 중요합니다. 따라서 이 데이터를 올바르게 표시하는 것이 매우 중요합니다.

DateTime 특성

DateTime 특성은 Mendix 플랫폼 내에서 날짜 및 시간 값을 저장하는 데 사용됩니다. 날짜와 시간 또는 두 구성 요소는 입력 위젯 구성 및 마이크로플로우의 변경 사항에 따라 설정됩니다. DateTime 값은 항상 Unix epoch라고도 하는 1970년 1월 1일 00:00:00 UTC 이후의 초 수로 데이터베이스에 저장됩니다. 이는 데이터베이스와 응용 프로그램에서 날짜 및 시간 값을 계산하고 저장하기 위한 일반적인 표준입니다.

지역화
DateTime 특성에는 해당 값을 지역화할 수 있는 옵션이 있습니다. 기본적으로 이 기능은 켜져 있으며 DateTime 속성이 애플리케이션의 nanoflows에서 표시 및/또는 사용될 때 브라우저의 시간대(대부분의 경우 클라이언트(브라우저)를 실행하는 시스템(장치) 시간대)를 통합하는 시간으로 형식이 지정됩니다. 끄면 UTC 값이 표시됩니다.

이는 새 DateTime 값을 입력하고 읽는 데 영향을 줍니다. 오프셋 UTC-6이 있는 시간대를 가진 사용자를 예로 들어 보겠습니다. 해당 사용자가 속성이 지역화된 경우와 지역화되지 않은 경우 날짜 선택기를 사용하여 2020년 7월 11일 날짜를 선택하면 어떻게 됩니까?

현지화가 켜져 있으면 선택한 날짜 및 시간 구성 요소는 07/11/2020 12:00 AM이 됩니다. 이 값은 UTC 07/11/2020 06:00 AM으로 저장됩니다. 동일한 사용자가 이 값을 보면 07/11/2020 12:00 AM으로 다시 변환됩니다. UTC+4의 표준 시간대 오프셋을 가진 다른 사용자가 데이터를 볼 때 값은 07/11/2020 10:00 AM이 됩니다.

현지화가 꺼져 있으면 선택한 날짜 및 시간 구성 요소는 07/11/2020 12:00 AM이 됩니다. 저장된 값은 07/11/2020 12:00 AM이고 UTC+4 오프셋이 있는 사용자는 날짜를 07/11/2020 12:00 AM으로 표시합니다. 따라서 다른 시간대에서의 선택, 저장 및 보기는 항상 동일합니다.

지역화	데이터베이스	사용자 UTC-6	사용자 UTC+4
YES	07/11/2020 06:00 AM	07/11/2020 12:00 AM	07/11/2020 10:00 AM
NO	07/11/2020 12:00 AM	07/11/2020 12:00 AM	07/11/2020 12:00 AM

로컬라이제이션을 언제 사용할지 여부를 결정하고 사용자와 마이크로플로우에 미치는 영향에 대해서는 다음 강의에서 논의할 것입니다.

시간대 설정

이 강의에서는 특정 시간대를 구성할 수 있는 위치와 이러한 시간대가 사용되는 시기에 대해 설명합니다.

Mendix에서는 사용자, 앱 설정 및 예약된 이벤트의 세 위치에서 시간대를 구성할 수 있습니다. 시간대를 구성하면 UTC 표현식을 사용하지 않는 한 애플리케이션 서버에서 XPath 및 마이크로플로우 표현식의 날짜 비교를 위해 시간대가 사용됩니다.

사용자
사용자에 대한 표준 시간대 설정은 이 사용자에 대해 작업을 수행할 때 사용되는 표준 시간대를 정의합니다.

앱 설정
기본 시간대입니다. 설정된 경우 설정된 표준 시간대가 없는 사용자에게 적용되는 표준 시간대입니다.

예약된 이벤트
이 설정은 예약된 이벤트 활동이 작동하는 표준 시간대를 정의합니다(예: 일정 이벤트 내의 활동에 적용되는 표준 시간대). 이는 예정된 이벤트가 실행될 때와 다르며, 이는 시작 순간과 인터벌 간격을 정의하여 예약된 이벤트 실행에 관여합니다.

이러한 시간대는 애플리케이션 서버에서 DateTime 값을 처리할 때 사용됩니다. 저장된 UTC 날짜는 설정된 시간대에 따라 변환됩니다.
Mendix 플랫폼에는 사용자 및 앱 시간대가 모두 설정되지 않은 경우 대체 메커니즘이 포함되어 있습니다. 이 대체 메커니즘이 적용되면 플랫폼은 클라이언트 브라우저에서 보고한 UTC의 브라우저 오프셋을 기반으로 DateTime 값의 형식을 지정합니다. 이 대체 메커니즘의 단점은 사용자의 표준 시간대를 알 수 없기 때문에 일광 절약 시간제를 고려할 수 없다는 것입니다. 이로 인해 사용자가 DST 변경에 걸쳐 있는 날짜로 작업을 시작할 때 잘못된 날짜 계산이 발생할 수 있습니다.

올바른 표준 시간대
앱에서 표준 시간대를 효과적으로 구성하는 방법을 결정하려면 먼저 대부분의 사용자가 단일 표준 시간대에 있는지 아니면 여러 표준 시간대에 있는지 확인하는 것이 중요합니다.

단일 표준 시간대 앱
모든 사용자가 단일 표준 시간대에 있는 경우 이 표준 시간대를 앱의 기본 표준 시간대(수준 1)로 설정하는 것이 좋습니다. 이런 식으로 앱의 새 사용자는 자동으로 시간대가 올바르게 설정됩니다.

여러 표준 시간대 앱
사용자가 여러 표준 시간대에 있는 경우 올바른 표준 시간대로 프로비저닝되었는지 확인하는 다양한 방법이 있습니다.

서버 작업에서 DateTime 서식에 사용자의 현재 UTC 오프셋(브라우저에서 파생됨)을 사용하도록 아무 작업도 수행하지 않습니다. 이는 표준 시간대를 설정하는 것에 대한 합리적인 대안입니다. 위에서 설명한 것처럼 일광 절약 시간제 변경만 제대로 처리되지 않습니다.
사용자가 자신의 표준 시간대를 수동으로 설정할 수 있도록 허용합니다. 예를 들어, 사용자가 자신의 계정을 관리하는 양식에 시간대 참조 선택기를 추가하여 이 작업을 수행할 수 있습니다(기본적으로 관리 모듈의 MyAccount). 이 방법을 선택할 때 시간대는 사용자가 로그아웃했다가 다시 로그인한 후에만 효과적으로 적용된다는 점을 명심하십시오.
각 사용자의 시간대를 수동으로 설정하고(관리자가 수행) 관리자가 계정을 관리하는 양식에 시간대 참조 선택기를 추가합니다(기본적으로 관리 모듈에서 Account_NewEdit). 응용 프로그램에 사용자가 너무 많지 않은 경우 실행 가능한 솔루션입니다.
microflow를 사용하여 시간대를 자동으로 설정합니다. 애플리케이션이 몇 개의 표준 시간대에서 사용되고 어떤 사용자에게 할당해야 하는 표준 시간대를 자동으로 결정할 수 있는 경우(예: 외부 시스템의 데이터 사용) "시작 후" 마이크로 플로우를 구성하여 올바른 표준 시간대를 설정할 수 있습니다.

이제 브라우저의 날짜 표시가 브라우저의 표준 시간대와 지역화가 켜져 있는지 여부에 따라 달라진다는 것을 알았습니다. 또한 사용자 또는 앱의 시간대는 애플리케이션 서버에서 날짜가 처리될 때 적용된다는 것을 알고 있습니다.

다음 강의에서는 지역화(Localize)를 No로 전환하는 시기에 대해 논의할 것입니다.

지역화하지 말아야 할 때

이전 강의에서는 시간대를 서로 다른 수준에서 구성하는 방법과 DateTime 처리가 이러한 설정에 따라 작동하는 방식에 대해 설명했습니다. 이 동작은 지역화된 DateTime 특성에 적용되며 DateTime 특성의 기본 설정입니다. 필요에 따라 Localize를 No로 설정할 수도 있습니다. 지역화되지 않은 DateTime 특성은 표시될 때 해당 표준 시간대로 지역화되지 않습니다. 사용자는 클라이언트에서 항상 UTC 값을 볼 수 있습니다.

시간 오프셋이 사용자와 관련이 없는 경우 지역화를 끌 수 있습니다. 예를 들어, 특정 위치에서 강의실 과정 일정을 생각해 보십시오. 이 일정에는 다음 정보가 필요합니다.

정보	일정 데이터 예제
위치	보스턴
날짜	07/11/2020
시작 시간	오전 9시
종료 시간	오후 4시

보스턴(표준 시간대 EDT UTC-4)의 사용자와 암스테르담(표준 시간대 CEST UTC+2)의 사용자가 일정을 볼 때 DateTime 속성이 지역화될 때 다음 정보를 볼 수 있습니다.

정보	사용자 보스턴	사용자 암스테르담
위치	보스턴	보스턴
날짜	07/11/2020	07/11/2020
시작 시간	오전 9시	오후 3시
종료 시간	오후 4시	오후 10시

DateTime 특성이 지역화되지 않은 경우 다음 정보가 표시됩니다.

정보	사용자 보스턴	사용자 암스테르담
위치	보스턴	보스턴
날짜	07/11/2020	07/11/2020
시작 시간	오전 9시	오전 9시
종료 시간	오후 4시	오후 4시

이 예제에서는 DateTime 특성을 지역화하지 않는 것이 논리적입니다.

위치가 명확하기 때문에 모든 곳에서 동일한 날짜와 시간을 표시하는 것이 더 읽기 쉽습니다. 날짜와 시간이 사용자에게 지역화된 경우 혼동을 일으킬 수도 있습니다. 사용자가 오스트레일리아 시드니(표준 시간대 AEDT UTC+11:00)에서 일정을 보고 있다고 상상해 보십시오. 이 시나리오에서 날짜는 2020년 7월 12일이 됩니다. 해당 사용자가 보스턴에서 과정에 참석하기를 원하고 항공편을 예약해야 했지만 시간을 보스턴 시간대로 다시 변환하지 않은 경우 하루 늦게 도착할 수 있습니다!

결론적으로 DateTime 특성을 사용하기 전에 사용자가 값을 읽는 방법과 프로세스에서 값을 사용하는 방법을 결정하십시오. 시간 오프셋이 관련이 없는 경우 localize를 No로 설정해야 합니다.

다음 강의에서는 DateTime 값을 사용하여 응용 프로그램 서버에서 어떤 일이 발생하는지 살펴보겠습니다.

응용 프로그램 서버의 Date Magic

이제 클라이언트에서 처리되는 날짜가 지역화가 켜져 있는지 여부에 따라 클라이언트 표준 시간대에 따라 작동한다는 것을 알았습니다. 그러나 응용 프로그램 서버에서는 사용자의 표준 시간대를 확인하고 DateTime 값의 서식을 지정하기 위해 특정 표현식 집합에 액세스할 수 있으므로 훨씬 더 많은 제어 기능을 사용할 수 있습니다.

UTC로 또는 UTC가 아님

Mendix 문서에서( 식 | Mendix 문서 ) DateTime 관련 표현식을 보면 대부분이 UTC 변형, 즉 formatDateTime() 및 formatDateTimeUTC() 를 가지고 있음을 알 수 있습니다.
UTC 표현식은 DateTime 속성 또는 변수의 UTC 값을 사용하는 반면, 비 UTC 표현식은 사용자 또는 앱 시간대를 기반으로 지역화된 시간을 사용합니다.

날짜 선택기 위젯을 사용할 때 날짜의 시간 구성 요소는 하루의 시작인 오전 12:00로 설정됩니다. 암스테르담(UTC+2)과 보스턴(UTC-4)의 사용자 두 명의 예를 살펴보겠습니다. 둘 다 07/11/2020 12:00AM 날짜를 선택하고 UTC와 UTC가 아닌 표현식을 모두 사용하여 날짜 형식을 지정하면 어떻게 될까요? 좀 더 복잡하게 말하자면, 날짜가 지역화될 때와 그렇지 않을 때 어떤 일이 발생할까요?

이 테스트의 결과에서 우리는 지역화된 속성을 처리할 때는 UTC가 아닌 형식을 사용해야 하고 지역화되지 않은 속성을 처리할 때는 UTC 식을 사용해야 한다는 결론을 내릴 수 있습니다.

formatDateTime(UTC) 식을 사용하는 경우 DateTime 값은 모든 DateTime 식에 대해 동일하게 처리됩니다. 우리의 소중한 지구는 둥글고 우리 대부분의 인간은 직선으로 생각하기 때문에 DateTime 값, 표준 시간대, 지역화 및 날짜 계산은 항상 어려울 것입니다. 모델링할 때 항상 위의 개념을 사용하여 올바른 선택을 한 다음 테스트, 테스트 및 테스트하십시오! 그리고 대표적인 테스트 데이터 세트 및 사용자 설정으로 테스트하십시오, 그렇지 않으면 속을 수 있습니다.

DateTime 값을 처리하는 방법에 대한 자세한 내용은 설명서에서 확인할 수 있습니다.( 날짜/시간 처리 FAQ | Mendix 문서 )

다음 강의에서는 몇 가지 테스트를 수행하여 UTC 및 비 UTC 함수와 함께 지역화된 dateTime 속성과 지역화되지 않은 dateTime 속성을 사용할 때 어떤 일이 발생하는지 확인합니다.

업무에서 DateTime 값 보기

이 연습에서는 formatDateTime 마이크로플로우 표현식과 함께 지역화된 설정과 지역화되지 않은 설정 간의 차이점을 실험합니다. 이는 사용자 시간대와 표현식의 (잘못된) 사용이 DateTime 값이 반환되는 방식에 영향을 미친다는 것을 보여줍니다.

응용 프로그램을 로컬로 실행합니다.
다음을 사용하여 로그인: Adrian/Mendix123
경기 개요로 이동합니다.
매치 중 하나를 엽니다.
열린 팝업은 아래 그림과 같아야 합니다.
Europe/Amsterdam 시간대에 있는 경우 지역화된 날짜/시간 값과 지역화되지 않은 날짜/시간 값이 동일합니다. 브라우저 / 시스템 시간대가 유럽 / 암스테르담과 다른 경우 오프셋에 따라 다른 현지화 된 날짜와 시간이 표시됩니다.