Проблема. Сохраняю DateTime.Now в строку с нужным мне форматом:




Потом эту дату строкой пишу в куки пользователю. Потом приходит эта кука мне от пользователя, и я сравниваю её с DateTime.Now. Под дебагом смотрю - DateTime.Now = 4/8/2014, а DateTime, который получился у меня после конвертации из строки клиента методом




равен 8/4/2014.

А должны быть равны.

Как сделать их равными?

Есть подозрение, что если для ToString использовал одну культуру, то и для парсинга ту же самую культуру нужно использовать. Если другую культуру буду использовать - получу неравенство для фактически равных дат. Так?

skyANAuser7320Есть подозрение, что если для ToString использовал одну культуру, то и для парсинга ту же самую культуру нужно использовать. Если другую культуру буду использовать - получу неравенство для фактически равных дат. Так?Да, верно.
А это значит, что эту культуру надо где-то сохранять, т. к. если юзер поменял культуру (например, раскладку переключил), то CurrentCulture уже другую культуру будет иметь. Так?



carrotikuser7320,

... как мне кажется, в подобных случаях (когда не уверен, в каких папуа-ново-гвинеях сидит клиент) нужно использовать либо UtcNow, либо CreateSpecificCulture(en-US), например, чтобы отойти от этих культур и часовых поясов ...
У меня проблема в формате вывода времени. Мне нужно одновременно и культуру сохранить, и в строку дату-время вывести с нужным ограничением. Т. е. я хочу вывести только число, месяц, год, часы, минуты, секунды. Пишу "dd/MM/yyyy" - хоппа, это формат для ru-культур! Т. е. получается, что культура задаётся не только через объект CultureInfo, но и через форматирующую строку!



При текущей культуре en-us вывожу как "dd/MM/yyyy HH:mm:ss". При парсинге с той же текущей культурой, что и при выводе, получаю как "MM/dd/yyyy HH:mm:ss" - т. е. перепутанные местами числа и месяцы. СПРАШИВАЕТСЯ, ПОЧЕМУ ФОРМАТ ВЫВОДА ВЛИЯЕТ НА КУЛЬТУРУ?!

Получается, что, чтобы формат вывода не влиял на культуру, всегда надо вместе с форматом использовать и CultureInfo?

Вобщем, сделал так. Завёл себе статичное поле типа CultureInfo с нужной мне культурой, вбитой ручками. И статичное строковое поле с форматом "dd/MM/yyyy HH:mm:ss". И теперь все даты к этой культуре привожу при выводе в строку и парсинге, а при только выводе в строку ещё и этот формат добавляю. Вроде, пока всё работает, как я хотел.

Как я понял, сам формат хранения даты и времени в DateTime культурнонезависимый (т. к. всё по отдельным компонентам хранится), а культура и формат влияют только на вывод (в строку) и парсинг.

hVosttВ англо-американской культуре в начале идёт месяц, в русской наоборот. Если вам так важна культура, не указывайте формат даты как dd/MM/yyyy, используйте общий формат: Строки стандартных форматов даты и времени
Да, я знаю. Ещё заметил, что "инвариантная" и "стандартная" культура - американская. Кто бы сомневался. )))

carrotikuser7320
Да, я знаю. Ещё заметил, что "инвариантная" и "стандартная" культура - американская. Кто бы сомневался. )))

...если придется когда-либо общаться программно с почтовым сервером по IMAP-протоколу, то там формат даты только такой: dd-MMM-yyyy, т.е. вида 08-Apr-2014, и хучьубей ...
Это не "инвариантная и стандартная"? Т. е., надо просто подстроиться под протокол, и всё будет хорошо?

carrotikuser7320Это не "инвариантная и стандартная"? Т. е., надо просто подстроиться под протокол, и всё будет хорошо?

... в данном конкретном случае - да ... Но стандарты протокола IMAP живут и побеждают уже лет эдак 30 и никто ничего менять не хочет ...
Наверное, просто всем по...

Культуристuser7320,

вот это вот MM/dd/yyyy
это уже не культура
это - бескультурие !
А ещё у них недесятичная метрическая система!

Но зато нельзя в двойное отрицание.

st_stЧем timestamp ненравится? Засунул число в куки и переводи потом куда хошь, в любой формат, хоть на сервере, хоть на клиенте.
Я ещё сравниваю на устаревание. С чем сравнивать на стуревание? - С DateTime.Now - как раз подходит. А как сравнить TimeStamp с DateTime?

st_stalert(Date.parse('09.04.2014 5:27:27')); // NaN
Я говно-джаваскрипт стараюсь не использовать.

skyANAuser7320пропущено...

Я ещё сравниваю на устаревание.В Cookie писать дату, которую проверять на устаревание. Любопытно, а expires почему не подходит?
Потому что я ещё добавляю к дате мусор в разные места (и чтобы длина полученной строки менялась) и хеширую всё это дело. На сервере, соответственно, обратно всё очищаю. "Чтобы никто не догадался", что я там храню.

skyANAuser7320Я говно-джаваскрипт стараюсь не использовать.Пишу говно на c#
Ага. )

zadral


15853545 - inogda luchshe zevatj chem govoritj....
Спасибо, щас проверю.

Только вместо ParseExact(now, "s", null) надо, наверное, ParseExact(now, "s", CultureInfo.InvariantCulture)?

ЗЫ. Привет, МСУ. Сколько раз уже штангу поднимаешь и сколько килограмм? Я как-то давно делал 80кг х 5 раз, но щас всё больше на подтягивания.

skyANA,

http://www.sql.ru/forum/1083013/budet-li-rabotat-takaya-shema

zadolbalЗы: ложил я на твоего мсу с прибором...
Тогда ты Антонарий или Сева.

zadolbal 15855910 - chitaj mani!!! "s" - sortable format !!! on i tak berjot invariantnuju kuljturu i tuda i obratno!!!!
http://msdn.microsoft.com/ru-ru/library/az4se3k1.aspx#Sortable
Я понял, почему мне не охота читать те мануалы. Потому что дизайн такого решения - говно. Я должен запомнить хренову тучу неинформативных СТРОКОВЫХ (т. е. без валидации just in code time) параметров. Вместо более подходящего для этого enum, по которому и Интеллисенс работает, и комментарии к каждому значению перечисления можно написать. Нет, блин, вместо этого вот вам кучка букв из алфавита. Такое ощущение, что эту часть фреймворка дизайнили чуваки из 70-80-х, когда передавать всё строками буквами и цифрами (-1 у нас это, 0 - то, 1, 2 и 3 - тоже зарезервированы) было модно не было другого выхода из-за ограничений железа, и нужно было постоянно держать под рукой справочник на каждую функцию, чтобы знать, что значит та ни о чём не говорящая циферка или буковка, которую она возвращает или принимает.

Вот я и инстинктивно сразу закрываю эту скатерть с разбором алфавита, и ищу более простое решение. Мне проще написать три-пять своих строк в своём классе, которые другой человек может быстро посмотреть и понять, что они делают (тем более, что я комментарий напишу), даже если это велосипед, чем заставлять себя или этого же человека идти и искать описание "s" или "D" и всей проче сопутствующей фигни.

мсущкоВсем привет! :)
Не, пока железки задвинул. Пиво по выходным, работа по будням, с семьёй по вечерам после работы. Веселуха ёпт ))
Как оно тут у вас?
Ты не МСУ. Ты Антонарий или Сева. ))

st_stПри желании TimeStamp <==> DateTime - одна строка кода. Культура влияет не только на даты, но и на разделитель дробных чисел, прятное ещё впереди.

p.s. думал аффтар уже успокоился с темой защиты от пиратов, но видимо упорно идём фперёт
Вы так говорите, как будто это дело заранее бестолковое, все давно об этом знают, но только я об этом не знаю. И вот "отцы программирования" собрались тут и ради развлечения делают ставки под пивко "бросит через месяц", "нет, уже через неделю" и т. п. Но в чём суть бестолковости - не говорят, чтобы веселье не закончилось раньше, чем пивко.

Ну т. е. вы согласны, что строковые параметры - говно? И что энумы были бы лучше?

"Вот поэтому я их и не читаю..."

bazileuser7320Ну т. е. вы согласны, что строковые параметры - говно? И что энумы были бы лучше?
Нет. Попробуй привести пример с enum-ми для свой же записи - DateTime.Now.ToString("dd/MM/yyyy") и ты увидишь насколько он будет длиннее. Ты просто ленишься и ищешь оправдания этой лени.
Не, согласен - где надо кастомный формат составить, типа комбинации из дней, месяцев, минут и прочего, то тогда строка лучший вариант, т. к. слишком много комбинаций. А когда заранее готовые форматы, которые у них там во фреймворке буквами обозначаются, которые ничего не говорят ("s", "d", "H" и т. д.) - то это лучше энумами.

bazileuser7320, и тогда бы пришлось изучать две вещи - enum и строковые форматы - вместо одной. Пришлось бы ради enum-ов делать отдельные перегруженные функции.
Какие перегрузки? Наверняка там внутри обычный switch стоит, который разбирает все эти s,d, H и прочее. У меня бы стоял тот же свитч, только по энумам.

bazileuser7320буквами обозначаются, которые ничего не говорят ("s", "d", "H" и т. д.)
Они ничего не говорят только не прочитавшим документацию
Самодокументированный и удобный код, это когда выбираешь из выпадающего списка готовые варианты, а тебе по каждому комментарий всплывает. И не надо в МСДН лазить. МСДН для совсем уж таких случаев, когда прямо непонятно или надо слишком много пояснять. А с DateTime.ToString с самого начала без документации не разберёшься - её надо не просто прочитать, а прочитать раз так двадцать и всё равно держать под рукой (на стене перед собой) распечатку шпаргалок, чтобы сносно этим кодом пользоваться. Только кто работает с этой фигнёй постоянно, через пару месяцев сможет обходиться без таких извращений. Слишком много времени и усилий ради сраной даты в виде строки. Стиль 70-80-х.

hVosttuser7320,




и как ты предлагаешь мне туда какой-то enum впендючить?
харе мозги колупать, не разобравшись в теме!
Вместо "s" напиши как надо: "dd:HH:yyyy" или там что ещё. Главное, не заставляй меня читать простыни про алфавит в виде параметров.

Это вы привыкши к этому говну, а для меня это WAT?!!!

Я победил!

Ладно, почитаю я эти ваши Format Strings... Но только Format Strings!