UTC или местное время со смещением зоны для моей схемы?

Question

Я определяю схему для своего веб-сервиса, к которому будут обращаться из разных стран.Мне интересно , какой из приведенных ниже 2 следует использовать (оба действительны в соответствии с типом xsd dateTime и ISO 8601) и , который из них является WS-I-совместимым ?

1. UTC формат 14: 15Z или 14: 15: 00Z.Добавленная буква Z указывает, что время представлено в UTC.
2. В качестве альтернативы используйте местное время с явным обозначением зоны в одном из форматов [+/-] чч: мм.Пример: 12: 15 + 02: 00

Answer 1

Это несколько субъективно - оба в порядке. Я предпочитаю UTC. В любом случае вам, скорее всего, необходимо преобразовать время в локальное клиентское устройство (и для этого вам следует полагаться на информацию, полученную от клиента, поскольку пользователь может войти в систему из разных часовых поясов). При хранении в формате UTC вам не нужно беспокоиться о деталях того, как происходит хранение, поскольку все времена представлены в одном и том же часовом поясе, и их намного легче сравнивать (и, следовательно, сортировать).

Answer 2

Обе формы соответствуют Основному профилю WS-I, так как они являются допустимыми лексическими форматами для xsd: dateTime.

Обычно в описании службы указывается xsd: dateTime в схеме и обычно не ограничиваетЛексический формат далее.В этом случае реализация службы должна быть готова обрабатывать любое допустимое значение xsd: dateTime, т. Е. Должна быть в состоянии справиться с любой формой в данных, полученных от клиентов.

Если вы действительно хотите, вы можете ограничить разрешенную лексическуюформатирует в схеме описание вашего сервиса, определяя пользовательский тип на основе xsd: dateTime с дополнительным аспектом шаблона.Полагаю, это все равно будет соответствовать профилю WS-I Basic, но я бы не стал этого делать, если у вас нет веских причин.По моему опыту пользовательские типы, основанные на типах XSD с добавленными фасетами шаблонов, не всегда хорошо работают со всеми наборами инструментов XML, поэтому вы можете создавать проблемы для клиентов, добавляя дополнительные ограничения помимо xsd: dateTime.

Answer 3

Зависит от варианта использования. Иногда полезно знать часовой пояс, в котором находится клиент. Если пользователь вводит время 13:00 в своем часовом поясе, он, вероятно, все еще хочет видеть 13:00 при получении даты.

Заметьте, я не говорю, что вы храните время в местном масштабе (что, конечно, было бы очень плохо), просто вы можете сохранить часовой пояс.