«Правильный» формат по умолчанию действительно зависит от того, что вы с ним делаете.Форматы синтаксического анализа, хранения и отображения могут быть разными.
Для хранения даты вы (почти) всегда захотите использовать UTC, как говорит aioobe, даже если вы хотите отобразить ее в пользовательскомместное время.Я говорю «(почти)», но я действительно не могу вспомнить случай, когда я бы не хотел бы UTC для сохраненной даты.Вы можете хотеть сохранить информацию TZ о том, где также возникла дата, так что вы можете сообщить об этом в это местное время, но чаще вы хотите отображать местное время для того, кто ищет в данный момент на дату.Это означает, что есть способ определить местное время текущего пользователя независимо от того, какое было первоначальное местное время.
Для его отображения «формат по умолчанию» обычно должен определяться языком зрителя.08/09/10 обычно означает 2010-август-9 в США (" Middle endian "), но обычно означает 2010-сентябрь-8 в большей части остального мира (" Little endian ").Формат ISO-8601 «2010-09-10» является безопасным и однозначным, но зачастую не тем, что люди ожидают увидеть.Вы также можете просмотреть RFC-3339 для даты и времени в Интернете и RFC-2822 для формата сообщения (передающего дату)
Для анализа даты:вы захотите проанализировать его и преобразовать в UTC, но вы должны быть достаточно гибкими в отношении того, что вы принимаете.Опять же, конечные пользователи Locale и часовой пояс, если их можно обнаружить, могут помочь вам определить, какой формат (ы) строки следует принимать в качестве входных данных.Это предполагает вводимые пользователем строки.Если вы генерируете метку даты / времени, вы можете управлять формой, и с разбором проблем не возникнет.
У меня также есть вторая ссылка BalusC , которую я раньше не видел и теперь добавил в избранное.