Внедрение DST в JavaScript, вызывающее проблемы при отправке на контроллер MVC

Ответ 1

Вы игнорируете часть .Net DateTime. В частности, вы не считаете, что свойство .Kind любого DateTime является одним из трех возможных значений DateTimeKind. Подробнее о MSDN.

Если вы работаете с значениями UTC, вам нужно установить DateTimeKind.Utc. Поскольку числовые значения JavaScript основаны на UTC, вы должны использовать это для преобразования:

DateTime dt = new DateTime(1970, 1, 1, 0, 0, 0, DateTimeKind.Utc)
                      .AddMilliseconds(1162267200000);

Кроме того, вы делаете что-то странное, используя форматер zzz на DateTime, который имеет DateTimeKind.Unspecified. В этом случае на самом деле нет никакого часового пояса, связанного со значением, но .Net предположит, что вы хотели, чтобы он вел себя так, как будто он был DateTimeKind.Local, так как форматер zzz не имеет смысла иначе.

Вам действительно нужно быть осторожным, чтобы не использовать значения DateTimeKind.Local (например, DateTime.Now) или что-либо, где неопределенные виды могут быть неверно истолкованы как локальные (например, zzz или .ToUniversalTime()). "Локальный" в этом контексте будет локальным для вашего сервера, что редко актуально в веб-приложении. Подробнее здесь.

Что касается реализации DST JavaScript, я сделал аналогичные замечания относительно спецификаций ECMAScript. Подробнее об этом можно прочитать здесь.

Теперь со всем сказанным вы попадаете в очень конкретную точку, а это значит, что ни JavaScript, ни .NET не предлагают тип, который представляет дату без времени. Оба придерживаются подхода, устанавливающего время до полуночи. Если вы не будете осторожны, вы можете столкнуться с проблемами с локальными датами, которые не имеют полночь, например 20 октября 2013 года в Бразилии. Если вы ограничены в США, тогда у вас может не быть этой конкретной проблемы, но она по-прежнему актуальна с точки зрения дизайна.

Лучшим подходом было бы использование истинного типа "дата без времени". В .Net вы можете найти это как LocalDate в Noda Time. Как строка ISO8601, она будет выглядеть как "2013-10-31" без какого-либо времени или часового пояса.

Если вы не хотите использовать Noda Time (хотя я очень рекомендую его), вы все равно можете использовать тип DateTime в .Net, просто будьте очень осторожны, чтобы никогда не использовать временную часть для чего-либо. Он должен иметь DateTimeKind.Unspecified.

К сожалению, в настоящий момент нет JavaScript-кода для JavaScript без даты. (Возможно, класс JavaScript Date был назван DateTime). Таким образом, вам нужно будет создать строку только для даты. Вы можете собрать его с помощью Date вручную, например:

var s = dt.getFullYear() + "-" + 
  (dt.getMonth() < 10 ? "0" : "") + dt.getMonth() + "-" + 
  (dt.getDate() < 10 ? "0" : "") + dt.getDate();

Но проще использовать библиотеку moment.js:

var s = moment(dt).format("YYYY-MM-DD");

Я просто предлагаю свое мнение относительно "лучшего подхода". Но если вы просто хотели бы знать, как предотвратить провал с тем, что вы сейчас делаете, то вы должны быть осторожны, чтобы не конвертировать в UTC в свой ответ JavaScript. Вы делаете это с помощью .toISOString(). Опять же, вы можете собрать полную дату и время вручную, или вы могли бы использовать момент, чтобы отформатировать ответ, относящийся к местному времени.

Если вы действительно думаете об этом, у Birthdate действительно нет связанного с ним времени или часового пояса. Большинство людей не отслеживают час/минуту/секунду своего рождения (или часовой пояс своего места рождения), когда они выясняют, сколько им лет. Вы можете сделать это для астрологии, но для повседневного использования бизнеса вы просто будете использовать начало дня в местном часовом поясе, где вы оцениваете возраст. Таким образом, дата действительно является единственной важной частью данных.