hVosttМСУ,

где нативное решение задачи? я правильно понимаю, вердикт такой — десерилизовать приведенные мною данные в приведенную структуру нельзя? или просто кто-то этого не умеет. потому что ....обожемой!..... данные не такие!
ISO-8601

Свой "формат" выбрось на свалку. Я тебе таких форматов сотню могу нагенерить. И что, будешь свой форматтер учить распознавать все форматы?

hVostt ты косить под дурачка долго будешь? Или правда не въезжаешь? Задача решается по второму пункту, ты чем читаешь? Десеришь в инт, а потом работаешь с ним как с датой у себя где-то в логике.
Сразу видно в soa ты не рубишь.

hVosttМСУ,

мда. всё. иди уже. «десеришь в инт». смехопанорама тебя уже заждалась.
Осилить не в состоянии? Бывает.

hVosttрешение опубликованной задачи




никаких свистоплясок с интами и прочей нечистью.
На помойку. Мне не нужен это гавнокод в прикладном коде. Иди 1С-никам, аксаптщикам и саповцам предложи с этим поработать. Что? Не знаешь, что это такое? Я не сомневался.

hVosttМСУ,

был дан детский пример. решения я так не увидел.

зато имел удовольствие лицезреть огромную, ну просто потрясающую кучу отмазок и попыток перевести тему. и про ISO-то мы поговорили, и про «неправильный» формат завели волынку, чего только мы не придумали.. чтобы оправдать свою неспособность решать простейшие задачки. одно бла-бла-бла.
Твой детский пример не удовлетворяет стандартизованным форматам. Как его решать - я тебе объяснил на пальцах. Что не понятно?

http://msdn.microsoft.com/ru-ru/library/bb412170.aspx Даты-времена и JSON
Формат JSON не предусматривает непосредственной поддержки дат и времен. Тем не менее, они очень часто используются, и в ASP.NET AJAX предусмотрена особая поддержка для этих типов. При использовании прокси-объектов ASP.NET AJAX тип DateTime в .NET полностью соответствует типу DateTime в JavaScript.
Если ASP.NET не используется, тип DateTime представляется в JSON в виде строки особого формата, который описан в разделе "Дополнительные сведения для опытных пользователей" ниже.
DateTimeOffset представляется в JSON как сложный тип: {"DateTime":dateTime,"OffsetMinutes":offsetMinutes}. Член offsetMinutes — это смещение местного времени относительно времени по Гринвичу (GMT, теперь также называемого временем в формате UTC), связанное с местоположением интересующего события. Член dateTime представляет момент времени, когда произошло интересующее событие (этот член тоже становится типом DateTime в JavaScript, когда используется ASP.NET AJAX, либо строкой, когда ASP.NET AJAX не используется). При сериализации член dateTime всегда сериализуется в GMT. Так, если описывается время 3:00 по Нью-Йорку, компонентом времени члена dateTime будет "8:00", а смещение в минутах offsetMinutes составит 300 (минус 300 минут, или 5 часов, относительно GMT).

ПримечаниеВ объектах DateTime и DateTimeOffset при сериализации в JSON информация сохраняется с точностью только до миллисекунд. Значения меньше миллисекунды (микро- и наносекунды) при сериализации теряются.

hVosttсуть была в том, чтобы показать расширяемость, которой Json.NET обладает, причем колоссальной расширяемостью, а родной сериализатор .NET — нет.
Да даром твоя расширяемость не впала :)

1. Либо пишешь свой JavaScriptConverter и регистрируешь его в JavaScriptSerializer
2. Либо делаешь вычисляемое свойство

http://api.stackoverflow.com/1.0/questions?sort=featured&type=jsontext







Всё. Чем твоя маркировка сторонним атрибутом лучше, чем использование нативных средств?

hVosttМСУ, в том, что приходит дата и время в формате Unix Time и я хочу работать именно с DateTime, а не с какими-то интами.
Мало ли, что ты хочешь. А если будут приходить два склеенных гуида и ты захочешь тоже работать с DateTime? Именно для этого созданы ISO стандарты, которые нужно соблюдать.

hVosttясен пень, что можно десериализовать в int, потом перебросить в DateTime.
Ну так а в чем тогда проблема?

hVosttчем своя лопата отличается от выверенной давно используемой сторонней библиотеки?
Тем, что она простая и очевидная, а самое главное - используется нативный проверенный сериализатор. Если я буду в проекте на каждый более менее нестандартный для .NET чих тащить левые сборки, то мой проект превратится в кучу неуправляемого неподдерживаемого навоза. Если задача решается одной строчкой кода, зачем мне тащить левую сборку для этого? Я бы еще понял, если бы эту левую сборку можно было бы оформить в виде несложного класса в виде хелпера, чтобы включить в свой проект. Но когда идет речь о левых тяжеловесных сборках, которые к тому же полностью заново переопределяют и дополняют возможности нативных сериализаторов - ну его в топку.

hVosttпри чем мы говорим не о наколенной поделки, какого-то забугорного Васи, а про библиотеку давно зарекомендовавшей себя, хорошо написанной и покрытой тестами, за что вполне заслуженно она включается в состав проекта ASP.NET MVC. заявлять, что это «тащить все говно с интернета в проект» — значит быть мягко говоря деревянным и невменяемым.
Да ничего она там не зарекомендованная, не неси ереси. Обычная левая приблуда для лентяев, которые по одной кнопке хотят сотворить мир. Которые не умеют работать со штатными возможностями. Вот такие и качают эту хрень. А тупорылые MS, у которых в башке один маркетинг, которые и так уже засрали студию чем только можно, включили этот лисапед в пакет. К MS на текущий момент очень много притензий, так что я не первый.

hVosttодна из способностей, которая отличает хорошего программиста, это умение повторно использовать готовые компоненты, написание собственных велосипедов должно быть сведено до минимума.
Умничка. Напиши базовый класс, конвертер для сериализатора или хелпер и используй на здоровье. Зачем мне твоя приблуда?

hVosttкстати, что странно в данном треде, что я тоже придерживаюсь минимализма, и стараюсь использовать сначала нативные методы
Не ври нам тут. У тебя в проектах, по всей видимости, все сборки интернета хостятся

hVosttмне хватает смелости, чтобы при возможности пользоваться готовыми качественными сторонними инструментами , и не только по причине «прижало», если это здорово сокращает время на разработку и делает проект в итоге лучше.
Хватает смелости - используй этот хлам. Я не запрещаю.

hVosttМСУ,

еще в приведенном тобою решении происходит постоянные вычисления (даже не кешируемые) при любом обращении. думаю это не тянет даже не говнокод, ибо в сотнях тысяч структур просадка производительности со всякими LINQ будет колоссальная. зря ты это привёл.
Садись, двойка. Это еще раз показывает твои знания и умения работать с геттерами свойств.




Как думаешь, при десериализации StackOverflow будет ошибка? Вопрос тебе на домашнее задании, без дневника не приходи.

hVosttдаже не кешируемые
Не нужно на ходу тут выдумывать дополнительные задачи. Если нужно кеширование значение - пишется доп. поле. Если нужен пересчет на лету - это другое требование. Всё зависит от задачи. Не фантазируй.

hVosttМСУ, я понял. ты живешь в идеальном мире и работаешь только с тем, что нативно поддерживается в .NET
Я живу не в идеальном мире и работаю много с чем. Но перед тем, как использовать тот или иной сторонний функционал, я минимум пытаюсь взвесить, насколько он будет оправдан. Пока не было таких задач, где я испытывал трудности с xml и json с помощью встроенного в fw функционала. Поверь мне, для этого не обязательно качать с кодплекса всякую муть.

hVosttесли заказчик тебе ставит задачу по приему и обработке данных которые не в ISO, ты его шлешь лесом, пусть дескать те товарищи сначала своё гумно к ISO приведут. ну и заказчик идёт, что ему еще...
Если формат данных заказчика нестандартен, я использую нативные инструменты для получения с последующей постобработкой. Никаких проблем, честное слово.

hVosttс гетерогенными системами тебе работать не доводилось, и за пределы разработки маленьких отчетных корпоративных приложений тебе выходить не приходилось.
Именно это я хотел бы сказать про тебя, особенно когда ты тут фантазировал про SOA на json (без xsd схем по сравнению с xml). Твои опусы просто забавляют.

hVosttмог бы посочувствовать. но на самом деле надо радоваться :) повезло тебе!
Выше.