2011-01-31 2 views
1

여러 국가에서 액세스 할 웹 서비스 스키마를 정의하고 있습니다. 나는 중 어느 쪽이 (둘 다 xsd dateTime 유형 및 ISO 8601에 따라 유효) 및 중 하나가 WS-I 호환입니까?내 스키마의 지역 오프셋이있는 UTC 또는 현지 시간?

  1. UTC (14)와 같은 형식 : 15Z 또는 14 : 15 : 00Z. 추가 된 Z 문자는 시간이 UTC로 표시됨을 나타냅니다.
  2. 또는 명시 적 영역 지정이 인 로컬 시간을 [+/-] hh : mm 형식 중 하나로 지정하십시오. 예 : 12 : 15 + 02 : 00

답변

3

다소 주관적입니다. 둘 다 괜찮습니다. 나는 UTC를 선호한다. 어쨌든 시간을 클라이언트 로컬로 변환해야 할 수도 있습니다 (사용자가 다른 시간대에서 로그인 할 수 있으므로 클라이언트의 정보에 의존해야합니다). UTC로 저장하면 모든 시간이 동일한 시간대에 표시되고 비교 (따라서 정렬)가 훨씬 쉬워 져서 스토리지가 발생하는 방식에 대한 세부적인 사항에 대해 걱정할 필요가 없습니다.

+0

+1 "최소한 UTC로 저장하면 두 번 datatimes를 더 빠르게 비교할 수 있습니다." –

1

사용 사례에 따라 다릅니다. 때로는 클라이언트가있는 시간대를 아는 것이 유용합니다. 사용자가 시간대에 13:00 시간을 입력하면 날짜를 검색 할 때 여전히 13:00을보고 싶어합니다.

참고로, 지역 시간대에 시간을 저장하는 것은 아닙니다 (물론 매우 나쁠 것입니다). 시간대를 유지하고 싶을 수도 있습니다.

1

두 형식 모두 xsd : dateTime에 대한 유효한 어휘 형식이므로 WS-I 기본 프로필과 함께 사용됩니다.

일반적으로 서비스 설명은 스키마에서 xsd : dateTime을 지정하며 일반적으로 어휘 형식을 더 이상 제한하지 않습니다. 이 경우 서비스 구현은 유효한 xsd : dateTime 값을 처리 할 준비가되어 있어야합니다. 즉, 클라이언트로부터받은 데이터에서 두 형식 중 하나를 처리 할 수 ​​있어야합니다.

정말로 원하는 경우 추가 패턴 패싯이있는 xsd : dateTime을 기반으로하는 사용자 정의 유형을 정의하여 서비스 설명을 위해 스키마에서 허용되는 어휘 형식을 제한 할 수 있습니다. 이것은 여전히 ​​WS-I 기본 프로파일을 준수 할 것이라고 나는 믿는다. 그러나 당신은 매우 설득력있는 이유가 없다면이 일을 피할 것이다. 필자의 경험에 따르면, 패턴 패싯이 추가 된 XSD 유형을 기반으로하는 사용자 정의 유형은 모든 XML 도구 세트와 항상 잘 작동하지 않으므로 xsd : dateTime 이외의 추가 제약 조건을 추가하여 클라이언트에 문제가 발생할 수 있습니다.

관련 문제