|
![]() |
#1 |
Участник
|
Ну на самом деле можно довольно легко забыть что дата в UTC и от нее надо получать локальную дату или пользоваться форматированным значением. Кроме того меня гложет мысль что я таки получал даты в локальном формате и не понятно почему это работает в SL и не работает в веб-приложении.
А еще меня просто убивает ситуация. которую я наблюдал сегодня и с которой собственно у меня встал весь этот вопрос: [13:45:20] Смотрю через SQL Start Date: 2006-12-31 13:00:00 Start Date UTC: 2006-12-31 21:00:00... То есть дата была добавлена с часовым поясом -8 [22:40:15] Опять смотрю через SQL Start Date: 2007-01-01 01:00:00 Start Date UTC: 2006-12-31 21:00:00 То есть нормальный часовой пояс +4 И a CRM на форме отображались днем 31 декабря, а сейчас вечером уже 1 января, при том что дата в UTC осталась той же самой... Днем я выполнял этот запрос не один раз, я даже написал о результате коллеге скопировав данные. я не мог ошибиться... А сейчас все совсем по другому... Как жешь так?... ![]() |
|
![]() |
#2 |
Участник
|
|
|
![]() |
#3 |
Участник
|
результат, выдаваемый FilteredView не зависит от времени на сервере. В частности сейчас на сервере часовой пояс +3, у пользователя +4 и данные выводятся именно с учетом этого. пользовательского пояса.
|
|
![]() |
#4 |
Участник
|
Согласен, а вот для клиенской машины того же сказать нельзя. Можно же заполнить дату на форме например, вызвав new Date() в JS. Не знаю как у вас там все выглядит.
Последний раз редактировалось lode; 28.03.2012 в 13:08. |
|
![]() |
#5 |
Участник
|
Цитата:
Посмотрите modifiedby, modifiedon в этой вьюшке, может правда кто-то поменял, или с бекапом сравните.. |
|
![]() |
#6 |
Участник
|
Цитата:
Блин, можно конечно все списать на какой то глюк, но на его "решение" потрачено полдня... обидно... |
|
Теги |
crm2011 |
|
|