WH>Кстати заметь ты сам написал "отображать". Календари нужны только но уровне интерфейса пользователя.
сильно упрощаете, календать нужен всегда, а не только в интерфейсе пользователя.
есть значительное кол-во задач по обработке данных выполняемых на сервере, которые требуют отнести дату к тому или иному часу, дню, дню недели, месяцу, году и т.д.
и здесь выясняется, что день по utc, это не тоже самое, что день по локальному времени.
и пользователи знать не хотят что такое utc, а хотят видеть свои любимые дни по локальному времени.
Здравствуйте, DarkGray, Вы писали:
DG>есть значительное кол-во задач по обработке данных выполняемых на сервере, которые требуют отнести дату к тому или иному часу, дню, дню недели, месяцу, году и т.д.
Например?
DG>и здесь выясняется, что день по utc, это не тоже самое, что день по локальному времени. DG>и пользователи знать не хотят что такое utc, а хотят видеть свои любимые дни по локальному времени.
Спасибо кэп.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
DG>>есть значительное кол-во задач по обработке данных выполняемых на сервере, которые требуют отнести дату к тому или иному часу, дню, дню недели, месяцу, году и т.д. WH>Например?
раз уж зашла речь о логах, то:
выдать записи за сегодня
зы
с одной стороны — эту задачу можно решать в лоб на стороне пользователя, заменяя сегодня при передаче на сервер на неудобовариемую пару:
[DateTime.Now.Date.ToUtc(), DateTime.Now.Date.AddDays(1).ToUtc()]
но если задача большая, то требуется предподготовка данных, и приходится определять что такое сегодня, вчера, текущая неделя и т.д. на стороне сервера до запроса пользователя.
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, DarkGray, Вы писали:
DG>>есть значительное кол-во задач по обработке данных выполняемых на сервере, которые требуют отнести дату к тому или иному часу, дню, дню недели, месяцу, году и т.д. WH>Например?
Здравствуйте, DarkGray, Вы писали:
DG>раз уж зашла речь о логах, то: DG>выдать записи за сегодня
Не мимо. Для логов лишние/недостающие 1% записей не играют роли.
Лучше взять какую-нить систему оплаты на основании данных входа/выхода на предприятие: опоздал -- штраф, задержался -- двойной тариф
Вот только не нужно говорить, что "сервер и клиенты в одной таймзоне будут".У нас сервер в Люксембурге, а заводы по всей Европе (но я не в курсе как там САП справляется ).
не устраивает?
Извини за прямоту но там: бред феерический.
Движку который считает загруженность дорого календарь не нужен. Вообще. Ему пофигу в какое время образовалась пробка.
Это важно только пользователю. А в интерфейсе пользователя у нас уже есть календарь.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, DarkGray, Вы писали:
DG>раз уж зашла речь о логах, то: DG>выдать записи за сегодня
Текстовые логи зло. Я в свое время с ними наплюхался.
Нагепать от туда что-то инересное порой весьма не просто.
DG>с одной стороны — эту задачу можно решать в лоб на стороне пользователя, заменяя сегодня при передаче на сервер на неудобовариемую пару: DG>[DateTime.Now.Date.ToUtc(), DateTime.Now.Date.AddDays(1).ToUtc()]
Именно так и надо делать.
Только не таким ужасным кодом конечно же.
DG>но если задача большая, то требуется предподготовка данных, и приходится определять что такое сегодня, вчера, текущая неделя и т.д. на стороне сервера до запроса пользователя.
А конкретно?
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
не устраивает? WH>Извини за прямоту но там: бред феерический.
Не вижу ничего страшного в прямоте.
WH>Движку который считает загруженность дорого календарь не нужен. Вообще. Ему пофигу в какое время образовалась пробка. WH>Это важно только пользователю. А в интерфейсе пользователя у нас уже есть календарь.
Честно говоря, не понял что ты называешь "Движком который считает загруженность дорог", но, например, движку маршрутизации, который ищет кратчайший по времени маршрут из точки A в точку B нужно знать текущее время и время проезда по заданной дороге в текущий момент времени. Очевидно, также, что для текущего момента времени лучше использовать UTC, чтобы корректно обрабатывать пересечения часовых поясов и переходы на летнее/зимнее время. А вот подсистеме, которая будет работать с данными и сообщать время проезда по данной дороге в данное время, локальное время может оказаться полезным, хотя бы, для работы с таким источником данных как TeleAtlas Speed Profiles (tm) или чем-нибудь аналогичным.
Здравствуйте, k.o., Вы писали:
KO>Честно говоря, не понял что ты называешь "Движком который считает загруженность дорог", но, например, движку маршрутизации, который ищет кратчайший по времени маршрут из точки A в точку B нужно знать текущее время и время проезда по заданной дороге в текущий момент времени.
И нафига тут локальное время?
KO>Очевидно, также, что для текущего момента времени лучше использовать UTC, чтобы корректно обрабатывать пересечения часовых поясов и переходы на летнее/зимнее время.
Во-во.
KO>А вот подсистеме, которая будет работать с данными и сообщать время проезда по данной дороге в данное время, локальное время может оказаться полезным, хотя бы, для работы с таким источником данных как TeleAtlas Speed Profiles (tm) или чем-нибудь аналогичным.
Зачем?
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, k.o., Вы писали:
KO>>Честно говоря, не понял что ты называешь "Движком который считает загруженность дорог", но, например, движку маршрутизации, который ищет кратчайший по времени маршрут из точки A в точку B нужно знать текущее время и время проезда по заданной дороге в текущий момент времени. WH>И нафига тут локальное время?
А я и не говорил, что оно тут нужно. Это контекст для, лучшего понимания примера, который приводится ниже.
KO>>Очевидно, также, что для текущего момента времени лучше использовать UTC, чтобы корректно обрабатывать пересечения часовых поясов и переходы на летнее/зимнее время. WH>Во-во.
KO>>А вот подсистеме, которая будет работать с данными и сообщать время проезда по данной дороге в данное время, локальное время может оказаться полезным, хотя бы, для работы с таким источником данных как TeleAtlas Speed Profiles (tm) или чем-нибудь аналогичным. WH>Зачем?
Оно там используется для более компактного представления данных. Как я уже говорил, скорость движения по дороге, хорошо коррелирует с локальным, для этой дороги, временем и эта зависимость может быть одинаковой для дорог из совершенно разных часовых поясов. Если хочешь подробностей почитай описание формата здесь, идея там очень простая. Использование локального времени выглядит там совершенно естественно, более того, если бы использовалось UTC, эти данные протухали-бы при любом изменении часовых поясов, да и и переход на летнее время непонятно как учитывать.
Здравствуйте, merge, Вы писали: M>Есть фильтр, где юзер вбивает даты начала и окончания для поиска. M>Если юзер не вбил любую или обе из дат, то интервал открыт для поиска.
M>Вот что по вашему лучше передавать в качестве даты в данном случае DateTime.MinValue или null?
1. Пользователь хочет искать что-то от начала времён до дня Д.
2. Интерфейс не позволяет ему выразить это желание явно, а заставляет не указывать начало интервала.
3. Пользователь не указывает начало интервала, и тем самым продолжает подразумевать, что надо искать от начала времён.
Начало времён ― это DateTime.MinValue.
---
since = DateTime.MinValue;
until = DateTime.MaxValue;
DG>>с одной стороны — эту задачу можно решать в лоб на стороне пользователя, заменяя сегодня при передаче на сервер на неудобовариемую пару: DG>>[DateTime.Now.Date.ToUtc(), DateTime.Now.Date.AddDays(1).ToUtc()] WH>Именно так и надо делать. WH>Только не таким ужасным кодом конечно же.
а каким?
DG>>но если задача большая, то требуется предподготовка данных, и приходится определять что такое сегодня, вчера, текущая неделя и т.д. на стороне сервера до запроса пользователя. WH>А конкретно?
всё аля OLAP: посчитать и хранить сколько происшествий было сегодня, вчера, позавчера, на этой недели, в прошлом месяце и т.д.
и вот все эти сегодня, этот месяц и т.д. пользователь ожидает что это будет localtime, а не какой-то там utc.
Здравствуйте, Sinclair, Вы писали:
V>>Ну тогда можно передавать не дату, а сразу тики. Кстати, эта возможность есть и сейчас, можно получить у DateTime long (64 бит) внутреннее значение, а затем воссоздать этот объект из этого значения. В базе данных можно хранить тогда просто эти тики. Ну и вполне принять за no-value какую-нить константу, например 0. S>Вопрос в семантике этих тиков. Косяк DateTime — в том, что эти тики могут отсчитываться от разных моментов.
Ну так информация об этом никуда не пропадает.
В бинарном представлении тиков в старших полях хранится признак — локальное это время, или UTC. В различных сценариях удобно оперировать различным представлением. "Удобно" в том плане, что не нужно каждый раз лезть в календарь и локаль часового пояса, чтобы преобразовывать даты на каждый чих. Ибо доступ к календарю и локальному часовому поясу очень тяжеловесен, т.к. выполняются блокировки на уровне даже не процесса, а вообще всей ОС.
А если хочется "чистоты", как тут проповедует Wolfhound, то все давно есть. Вернее, есть все запчасти, чтобы за 10 мин написать свой класс с произвольной логикой. Прими некую UTC дату за точку 0 в своем классе, и отсчитывай от него тики (TimeSpan).
class UtcTime {
long _ticks;
static long Zero = new DateTime(2000, 1, 1, 0, 0, 0).Ticks; // we count it as UTCpublic implicit operator UtcTime(DateTime dt) {
switch(dt.Kind) {
case DateTimeKind.Utc: return UtcTime(dt.Ticks);
case DateTimeKind.Local: return UtcTime(dt.ToUniversalTime(dt.Ticks));
}
throw InvaldArgumentException("Unspecified DateTime value");
}
public implicit operator DateTime(UtcDateTime dt) {
return new DateTime(Zero + _ticks, DateTimeKind.Utc);
}
...
// TODO: определить мемберы, аналогично мемберам DateTime
}
Здравствуйте, vdimas, Вы писали:
V>Ну так информация об этом никуда не пропадает.
Гм. Её как бы вовсе и нету.
V>В бинарном представлении тиков в старших полях хранится признак — локальное это время, или UTC.
Ага. Проблема только в том, что понятие "локальное" эквивалентно понятию "не знаю какое".
V> В различных сценариях удобно оперировать различным представлением. "Удобно" в том плане, что не нужно каждый раз лезть в календарь и локаль часового пояса, чтобы преобразовывать даты на каждый чих. Ибо доступ к календарю и локальному часовому поясу очень тяжеловесен, т.к. выполняются блокировки на уровне даже не процесса, а вообще всей ОС.
Вот это мне кажется, мягко говоря, преувеличением. Календарь — это математическая абстракция. Ничего блокировать ему не надо. А часовой пояс на чтение не должен как-то очень сильно напрягать систему.
V>А если хочется "чистоты", как тут проповедует Wolfhound, то все давно есть. Вернее, есть все запчасти, чтобы за 10 мин написать свой класс с произвольной логикой. Прими некую UTC дату за точку 0 в своем классе, и отсчитывай от него тики (TimeSpan).
Это всё понятно. Я и класс строки могу свой написать. Толку-то? Мы говорим о платформе. 100% окружающего кода будут отдавать мне дату не в TimeSpan, а в обычных DateTime. В которых мне опять придётся гадать, кто из них кто.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
V>>В бинарном представлении тиков в старших полях хранится признак — локальное это время, или UTC. S>Ага. Проблема только в том, что понятие "локальное" эквивалентно понятию "не знаю какое".
Это просто флаг, семантика использования которого зависит от добросовестности программиста.
Локально — это означает локальный ввод-вывод, и вычисления, привязанные к локальным моментам времени, не более того. В этом плане Wolfhound прав (с поправками от оппонентов).
Никакому пользователю не нужен UTC, разумеется, вот и используйте DateTime только для локального ввода-вывода.
V>> В различных сценариях удобно оперировать различным представлением. "Удобно" в том плане, что не нужно каждый раз лезть в календарь и локаль часового пояса, чтобы преобразовывать даты на каждый чих. Ибо доступ к календарю и локальному часовому поясу очень тяжеловесен, т.к. выполняются блокировки на уровне даже не процесса, а вообще всей ОС. S>Вот это мне кажется, мягко говоря, преувеличением. Календарь — это математическая абстракция. Ничего блокировать ему не надо. А часовой пояс на чтение не должен как-то очень сильно напрягать систему.
Как это не должен? Из любой другой программы тебе поменяют часовой пояс, и он у тебя должен тут же "подхватиться" в твоей программе. Никаких кеширований для доступа только по чтению календаря и часового пояса быть не может.
Если бы вся ОС была управляемой с GC, то для доступа по чтению действительно блокировки были бы не нужны, при условии атомарного чтения ссылки на объект и принятом соглашении, что при изменении . А т.к. ось нативная, то равнозначно блокируются операции чтения и записи ресурса.
V>>А если хочется "чистоты", как тут проповедует Wolfhound, то все давно есть. Вернее, есть все запчасти, чтобы за 10 мин написать свой класс с произвольной логикой. Прими некую UTC дату за точку 0 в своем классе, и отсчитывай от него тики (TimeSpan). S>Это всё понятно. Я и класс строки могу свой написать. Толку-то? Мы говорим о платформе. 100% окружающего кода будут отдавать мне дату не в TimeSpan, а в обычных DateTime. В которых мне опять придётся гадать, кто из них кто.
Ну так я ключевое и показал — это implicit операторы приведения типа.
А что правильнее? Поиск часто проводится в базе данных. В некоторых базах данных минимально возоможное время отличается от DateTime.MinValue в большую сторону, то есть передача DateTime.MinValue как параметра запроса приведет к ошибке.
Здравствуйте, ZevS, Вы писали:
ZS>Здравствуйте, alexzz, Вы писали:
A>>since = DateTime.MinValue; A>>until = DateTime.MaxValue;
A>>since = null; A>>until = null;
A>>Что понятнее?
ZS>А что правильнее? Поиск часто проводится в базе данных. В некоторых базах данных минимально возоможное время отличается от DateTime.MinValue в большую сторону, то есть передача DateTime.MinValue как параметра запроса приведет к ошибке.
Ещё поиск часто проводится не в базе данных. Автор не поставил вообще никаких условий.
Между прочим, в отличие от всего предыдущего словоблудия, которое тут развернулось, твой пост первый нормальный, потому что с чётким обоснованием.
Здравствуйте, alexzz, Вы писали:
A>Ещё поиск часто проводится не в базе данных. Автор не поставил вообще никаких условий.
Тем более глупо использовать занчение по-умолчанию, ведь тогда в списке, в которм мы собрались искать могут оказаться и даты меньше нашей минимальной по-умолчанию, и мы банально выберем не все значения. Многое, конечно, зависит от конкретной задачи.
Здравствуйте, Sinclair, Вы писали:
_FR>>И первое, что написали бы — это тип [DateTime, Calendar]; S>Именно, что первое. А подумав — пишут:
S>
S>Prior to JDK 1.1, the class Date had two additional functions. It allowed the interpretation of dates as year, month, day, hour, minute, and second values. [/b]
Ох, если бы все было так просто
Навскидку, вот: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6281408
Замечу, версия JDK не 1.0, не 1.1 и даже не 1.2 (а это все были очень даже полноценные релизы!).
Согласитесь, далеко от концепции "чисто дата + календарь", преведенной в данной ветке выше.
Т.е. оно по API и документации вроде бы как соответствует, а вот по факту — нет.
Что характерно, в 1.5 баг пофиксили. Внутрь не заглядывал, но с большой долей вероятности могу предположить, что концепция поменялась "в правильную" сторону — Date сделали более математически-абстрактной, не так сильно зависящей от настроек окружения. По крайней мере, надеюсь
А мораль сей басни — увы, но, похоже, декомпозиция такого, казалось бы, очевидного и простого понятия, как "дата" и "время" не так уж проста. Очень разный смысл иногда в них вкладывается. И главная проблема, что смысл чаще всего похожий, но все-таки не одинаковый.
И это даже в пределах одной платформы. А если разные — то все еще гораздо веселее в плане "одинаковости" концепций. Вот чисто навскидку (могу, конечно, ошибаться, а проверять немного лениво, но, может, кто-нибудь чуть больше в теме) — библиотеки Java вроде как поддерживает leap seconds, а .NET — нет. Наверняка при портировании или интеграции некоторых приложений кто-то уже поимел удовольствие долго и нудно искать потерянную секунду, а потом быстренько мигрировать на самописный велосипед
). 
