우리 응용 프로그램에서는 UTC DateTime을 DataBase에 저장합니다. 클라이언트 (자바 스크립트)가 Local TimeZone에 datetime을 보내고 컨트롤러 레벨에서 데이터베이스에 날짜를 저장하기 전에이를 UTC 시간으로 변환합니다.서버에서 클라이언트로 UTC 오프셋
클라이언트와 서버 모두 다른 시간대에 있습니다.
우리는 그래서 우리는 다시 컨트롤러 현지 날짜 시간에 날짜 시간을 변환해야
DateTime.SpecifyKind(_CreatedDate, DateTimeKind.Utc);
와 엔티티 프레임 워크를 사용하여 UTC의 데이터베이스에서 날짜를 가져 오는하거나 우리는 클라이언트에서 모든 날짜 시간 변환 로직을 처리해야합니다.
서버에 DateTime 인스턴스를 보낼 때 변환을 가능한 한 빨리 수행해야합니다.이 경우 클라이언트가 귀하의 클라이언트는 javascript이므로 toUTCString 메서드를 사용할 수 있습니다. momentjs를 사용하는 경우 utc을 사용할 수 있습니다.
서버에서 DateTime 인스턴스를 받으면 변환은 가능한 한 늦게 발생해야합니다. 지속 된 날짜/검색 날짜가 생성 될 때 UTC인지 확인하십시오. 다시 말하지만, 로컬 날짜 시간 인스턴스로 변환해야하는 것은 클라이언트입니다.
마지막으로 ISO8601 형식을 사용하여 클라이언트와 서버간에 모든 datetime 인스턴스를 보냅니다. Momentjs, javascript의 날짜 객체, json.net 모두이 작업을 수행 할 수 있습니다. 이렇게하면 아무 것도 잃어 버리지 않으며 문화적으로 특정한 버그가 발생하지 않습니다.
왜 클라이언트에서 처리해야하는지에 관해서는 매우 간단합니다. 가장 쉬운 방법입니다. 클라이언트 만이 진정으로 시간대를 알고 있기 때문에 서버 측에서 "정확하게 추측하기"는 대개 매우 어렵습니다. 이 작업을 수행하지 않는 유일한 이유는 사용자 프로필에 사용자 시간대 정보를 저장하려고하지만이 경우에도 매우 까다로울 수 있습니다 (사용자가 이동하거나 위치를 이동하면 어떻게되는지 등).
지속성에 관해서는 오프셋 유형 (DateTime 유형 또는 사용중인 RDBM에 따라 실제 유형 이름이있는 DateTime)을 사용할 수 있습니다. 그것이 저장되었을 때 utc로부터의 오프셋을 아는 것이 중요하다면 어느 것을 선택해야 하는가에 달려 있습니다. 지금까지 나는 이것을 할 필요가 없었지만 어쩌면 그것은 당신에게 중요 할 수 있습니다. DateTime은 UTC 시점을 나타내야하고 오프셋은 UTC 시점으로 되돌아 가기위한 오프셋을 사용하여 현지 시간을 나타내야하므로 실제 시점에 영향을 미치지 않습니다.
우리의 프로젝트에서 우리가하는 방식입니다. 제 의견으로는 데이터베이스에 datetimeoffset을 사용해야합니다. 이렇게하면 날짜가 저장된 시간대를 식별 할 수 있습니다. 그런 다음 클라이언트에서 서버로 날짜를 보낼 때 datetimeoffset으로 전송되었는지 확인하십시오.
datetimeoffset을 서버에서 클라이언트로 보낼 때 클라이언트 측에서 변환을 수행 할 수 있습니다. 나는 누구도 MomentJS Timezone이 이것을위한 최고의 라이브러리라고 주장하지 않을 것이라고 생각합니다. 저기를보고 총 맞춰보세요. DateTimeOffset으로
DateTimeOffset 정교화
는 DATETIMEOFFSET 제외한 날짜와 같은 다른 데이터 형식의 시간대를 결정하는 오프셋 시간을 추가한다. 예를 들어 중부 표준 시간대에있어 시간이 08:00 am 인 경우를 가정 해 봅시다. 음, Datetimeoffset에서 오프셋이 -4 (중앙 시간대)라고 선언하는 08:00:00:00 -04:00과 같을 것입니다. 이것은 읽을 때 머리에 어떤 수학도 할 필요가 없기 때문에 실제로 쉽게 변환 할 수 있습니다 (MomentJS가 당신을 위해 그것을하도록하십시오). 당신이 그것을 읽을 때, 당신은 항상 "아, 그것은 시간을 절약 한 사람을 위해 오전 8시 였고, 그들은 중앙 시간대에 그것을 저장 한 것처럼 보입니다."
이 변환 할 적절한 시간 인 경우 상대적인 값이 입니다.
내가 생각하는 유일한 절대 규칙은 유효합니다.
UTC 시간에 대한 어떤 시간대에 다른 변환이 단지 "표시"입니다
유일한 실제 의미있는 데이터 나를
당신이와 마찬가지로 그래서 동일한 규칙을 따릅니다 나머지 데이터.
뷰의 부울을 체크 박스로 변환하는 것과 같습니다. 서버에 체크 박스 값을 부울로 보내는 것과 같습니다.
그리고는 이 또는 잎UI에 도달 조속한입니다.
클라이언트 측에서 날짜를 비교할 때 우리가 직면하고있는 문제. 입력 날짜가 현지 시간대에 있기 때문에 해당 시나리오에서 솔루션이 어떻게 도움이되는지. –
사용자가 DateTime Picker에서 읽은 시간을 즉시 변환하여 클라이언트 측 비교가 UTC에서도 수행됩니다. 값이 UI (예 : 피커)를 벗어 났으므로 utc로 변환해야합니다. UI를 떠난다는 것은 피커에서 그것을 읽고 자바 스크립트 함수에 값으로 보냅니다. –
기본적으로 로컬에서 UTC로 또는 UTC에서 로컬로 변환하는 모든 작업은 클라이언트 측에서만 수행해야합니다. –
@vikas - 예, 클라이언트/브라우저는 항상 자체 시간대를 알아야하므로 해당 책임을 해당 시간대로 옮기는 것이 좋습니다. 예를 들면 : momentjs 인스턴스에서 toLocal을 호출하면 utc datetime이 해당 로켈의 올바른 datetime (브라우저 컴퓨터에 등록되어 있음)으로 변환됩니다. 클라이언트가 UTC로 datetime 스탬프를 보내면 같은 이유로 이치에 맞습니다. – Igor