Здравствуйте, chocho, Вы писали:
C>Здравствуйте,
C>Что-то я не понимаю проблемы с которой вы боретесь и за что ненавидите DateTime.
Мы не боремся. Мы с ленцой высказываем своё фи.
C>В распределённым приложении нужно работать с UTC временем, переводя его в локальное там где нужно.
С текущей реализацией DateTime — да.
C>Kind у DateTime это нормально потому что указав его я знаю как себя ведёт объект при передаче по ремоутингу, время действительно может быть Local, UTC и Unspecified.
Но ведь можно было DateTime реализовать так, что не пришлось бы зниматься этой шизофренией.
Здравствуйте, hardcase, Вы писали:
H>Но ведь можно было DateTime реализовать так, что не пришлось бы зниматься этой шизофренией.
Я против неявности.
Вы предлагаете полагаться на название переменных, типа startTimUTC.ToUniversalTime() не изменит переменную?
Или вы за разные типы для локального и UTC-шного времени?
Здравствуйте, chocho, Вы писали:
C>Я против неявности. C>Вы предлагаете полагаться на название переменных, типа startTimUTC.ToUniversalTime() не изменит переменную? C>Или вы за разные типы для локального и UTC-шного времени?
Я тут
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, chocho, Вы писали:
C>>Я против неявности. C>>Вы предлагаете полагаться на название переменных, типа startTimUTC.ToUniversalTime() не изменит переменную? C>>Или вы за разные типы для локального и UTC-шного времени? WH>Я тут
ну т.е. вы хотите чтобы DateTime был только UTC.
От этого фрэйврок не выиграл бы. Мне не раз нужно было рабоать с датами\временем, которые:
1. неопределены, просто некоторая дата и нам не важно из какой она таймзоны.
2. нужно отображать в таймзоне конкретного сервера.
Имхо, возможность работать с DateTime так как мне нужно в конкретном месте, это только плюс.
Например, возможность работать с локальным временем в подсистеме которая выполняется на текущей машине и завязаны на чужое API работающее с локальным временем.
Здравствуйте, WolfHound, Вы писали:
A>>А такое очень даже возможно в распределённых приложениях, например, клиентская программа находится в Москве в поясе UTC+3, а центральная БД, к которой идут запросы — в Лондоне с поясом UTC+0. WH>Это все по тому что индус который делал эти классы не удосужился подумать головой. WH>Единственно верный способ реализовать DateTime это зафиксировать некую точку во времени. WH>Например 01.01.2000 00:00:00 UTC+0 WH>Или любую другую по вкусу. WH>И отсчитывать от этой точки колличество наносекунд.
Ну тогда можно передавать не дату, а сразу тики. Кстати, эта возможность есть и сейчас, можно получить у DateTime long (64 бит) внутреннее значение, а затем воссоздать этот объект из этого значения. В базе данных можно хранить тогда просто эти тики. Ну и вполне принять за no-value какую-нить константу, например 0.
Здравствуйте, vdimas, Вы писали:
V>Ну тогда можно передавать не дату, а сразу тики. Кстати, эта возможность есть и сейчас, можно получить у DateTime long (64 бит) внутреннее значение, а затем воссоздать этот объект из этого значения. В базе данных можно хранить тогда просто эти тики. Ну и вполне принять за no-value какую-нить константу, например 0.
Что такое "статическая типизация" и зачем ее придумали знаешь?
Если да то должен понимать почему long не подходит.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, chocho, Вы писали:
C>ну т.е. вы хотите чтобы DateTime был только UTC.
Ты точно не читаешь.
Я не хочу чтобы DateTime что-то знал о календарях вообще и часовых поясах в частности.
Ибо это нарушение SRP.
И хотя некоторые не сознательные личности спорят но в данном случае (в прочем как обычно) нарушение SRP привело к вполне конкретным проблемам.
И в данной теме некоторые из них ьыли озвучены.
C>От этого фрэйврок не выиграл бы. Мне не раз нужно было рабоать с датами\временем, которые: C>1. неопределены, просто некоторая дата и нам не важно из какой она таймзоны.
Тут скорее ты себе внушил что не важно.
Ибо дата без таймзоны не имеет физического смысла.
C>2. нужно отображать в таймзоне конкретного сервера.
Получаем календарь с таймзоной сервера и спокойно отображаем. И нас не парит откуда мы получили дату и какой там часовой пояс.
Кстати заметь ты сам написал "отображать". Календари нужны только но уровне интерфейса пользователя.
C>Имхо, возможность работать с DateTime так как мне нужно в конкретном месте, это только плюс. C>Например, возможность работать с локальным временем в подсистеме которая выполняется на текущей машине и завязаны на чужое API работающее с локальным временем.
API завязаное на локальное время это само по себе кривь жуткая. Никогда не нарывался на проблемы с переводом часов на летнее/зимнее время?
А если это мобильный девайс и он пересекает часовые пояса?
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, chocho, Вы писали:
C>>ну т.е. вы хотите чтобы DateTime был только UTC. WH>Ты точно не читаешь. WH>Я не хочу чтобы DateTime что-то знал о календарях вообще и часовых поясах в частности.
Да, я прочитал по диагонали, сорри. Это ещё хуже, я без календаря не смогу даже залогировать дату.
WH>Ибо это нарушение SRP.
Возможно и нарушение, но интерфейс класса непротиворечив, имхо, и по-моему удобен. Возможно было бы лучше если бы он был обёрткой для набора классов.
Соглашусь, что для каких-то мифических задач может быть неудобен, ничто не мешает его использовать в 99% случаев, а в остальных написать свою реализацию.
WH>И хотя некоторые не сознательные личности спорят но в данном случае (в прочем как обычно) нарушение SRP привело к вполне конкретным проблемам. WH>И в данной теме некоторые из них ьыли озвучены.
C>>От этого фрэйврок не выиграл бы. Мне не раз нужно было рабоать с датами\временем, которые: C>>1. неопределены, просто некоторая дата и нам не важно из какой она таймзоны. WH>Тут скорее ты себе внушил что не важно. WH>Ибо дата без таймзоны не имеет физического смысла.
Когда фрэймворк за меня решает, что для меня лучше, имхо, это не правильно.
В данном случае значение даты интерпретирует юзер, а я только предоставляю фильтрацию по ней.
В будущем, возможно, что-то изменится, главное, что у меня есть выбор как поступить.
C>>2. нужно отображать в таймзоне конкретного сервера. WH>Получаем календарь с таймзоной сервера и спокойно отображаем. И нас не парит откуда мы получили дату и какой там часовой пояс. WH>Кстати заметь ты сам написал "отображать". Календари нужны только но уровне интерфейса пользователя.
Нужно как минимум логировать и как здорово было бы дебажиться с помощью mdbg видя вместо даты 64битное число.
C>>Имхо, возможность работать с DateTime так как мне нужно в конкретном месте, это только плюс. C>>Например, возможность работать с локальным временем в подсистеме которая выполняется на текущей машине и завязаны на чужое API работающее с локальным временем. WH>API завязаное на локальное время это само по себе кривь жуткая. Никогда не нарывался на проблемы с переводом часов на летнее/зимнее время? WH>А если это мобильный девайс и он пересекает часовые пояса?
Естественно речь о каком-нибудь небольшом компоненте который из таймзоны в таймзону не перелетает.
Просто есть возможность не постоянно конвертить время, а перевести его один раз и работать.
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, chocho, Вы писали:
C>>От этого фрэйврок не выиграл бы. Мне не раз нужно было рабоать с датами\временем, которые: C>>1. неопределены, просто некоторая дата и нам не важно из какой она таймзоны. WH>Тут скорее ты себе внушил что не важно. WH>Ибо дата без таймзоны не имеет физического смысла.
Иногда, всё-таки, имеет, также как имеет смысл использовать локальное время не только в UI. Например, для хранения/обработки данных о скорости движения на дорогах. Природа их такова, что утром и вечером, из-за пробок, скорость будет одинаково низкая, независимо от того где находится дорога: в Москве или Нью-Йорке. Я, разумеется, немного упрощаю, но в целом, всё так и есть.
Здравствуйте, chocho, Вы писали:
C>Да, я прочитал по диагонали, сорри. Это ещё хуже, я без календаря не смогу даже залогировать дату.
Как человек работавший в свое время с очень большими логами весьма плотно могу со всей ответственностью заявить что текстовые логи это очень злое зло.
C>Когда фрэймворк за меня решает, что для меня лучше, имхо, это не правильно.
А он всегда решает. И в данном случае нарешал такое что лучше бы вообще ничего не решал.
C>В данном случае значение даты интерпретирует юзер, а я только предоставляю фильтрацию по ней. C>В будущем, возможно, что-то изменится, главное, что у меня есть выбор как поступить.
И будешь ты разгребать где какая дата...
C>Естественно речь о каком-нибудь небольшом компоненте который из таймзоны в таймзону не перелетает. C>Просто есть возможность не постоянно конвертить время, а перевести его один раз и работать.
Это он сейчас не перелетает. А потом начнет.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
V>>Ну тогда можно передавать не дату, а сразу тики. Кстати, эта возможность есть и сейчас, можно получить у DateTime long (64 бит) внутреннее значение, а затем воссоздать этот объект из этого значения. В базе данных можно хранить тогда просто эти тики. Ну и вполне принять за no-value какую-нить константу, например 0. WH>Что такое "статическая типизация" и зачем ее придумали знаешь?
Догадываюсь.
WH>Если да то должен понимать почему long не подходит.
Не в ту область тебя занесло. Мы сейчас обсыждали "протокол" передачи DateTime из одной части системы, в другую. А представление данных в "протоколе" может не совпадать с оперируемыми на "логическом" уровне.
Здравствуйте, vdimas, Вы писали:
V>Не в ту область тебя занесло. Мы сейчас обсыждали "протокол" передачи DateTime из одной части системы, в другую. А представление данных в "протоколе" может не совпадать с оперируемыми на "логическом" уровне.
Не знаю что ты там обсуждаешь. Но я обсуждаю дизан класса DateTime и то как его сделать правильно.
А во что он там сериализуется меня не волнует.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
WH>Ибо локального времени не существует. Ну, намерения были хорошие:
There was a lot of desire to keep the type system simple, and while a time zone aware DateTime was better at representing absolute points in time such as a file time-stamp, it got awkward when doing certain things:
— Interoperating with database, COM or legacy systems where the time zone could not be reliably inferred.
— Representing genuinely abstract dates and time, e.g. the opening times for stores of a company spanning time zones.
— Representing whole dates, e.g. the type for a calendar control to return. (Obviously a “Date” type is an even better way of representing this, and many people have asked for separate Date and Time types, but in V1.0 there was a desire to keep the number of base types small to limit complexity of the platform. This feature request is definitely still on the table, although not planned for .NET 3.5).
Здравствуйте, _FRED_, Вы писали:
_FR>И первое, что написали бы — это тип [DateTime, Calendar];
Именно, что первое. А подумав — пишут:
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. It also allowed the formatting and parsing of date strings. Unfortunately, the API for these functions was not amenable to internationalization. As of JDK 1.1, the Calendar class should be used to convert between dates and time fields and the DateFormat class should be used to format and parse date strings. The corresponding methods in Date are deprecated.
V>Ну тогда можно передавать не дату, а сразу тики. Кстати, эта возможность есть и сейчас, можно получить у DateTime long (64 бит) внутреннее значение, а затем воссоздать этот объект из этого значения. В базе данных можно хранить тогда просто эти тики. Ну и вполне принять за no-value какую-нить константу, например 0.
Вопрос в семантике этих тиков. Косяк DateTime — в том, что эти тики могут отсчитываться от разных моментов.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, WolfHound, Вы писали:
C>>Я против неявности. C>>Вы предлагаете полагаться на название переменных, типа startTimUTC.ToUniversalTime() не изменит переменную? C>>Или вы за разные типы для локального и UTC-шного времени? WH>Я тут
По сути то, что ты хочешь от DateTime — это нехитрая такая обверточка над Long. Кто мешает реализовать свой тип подобным образом и сделать календарь для всех остальных операций — "заготовочного" кода, уверен, можно найти немало. И ругаться ни на кого не надо. Заодно можно показать людям "как правильно".
Это если действительно есть по работе большие проблемы с DateTime, а не так, к слову пришлось.
Здравствуйте, _FRED_, Вы писали:
_FR>А кто-то автоматически без ведома программиста преобразованиями занимается?
Да, имелись ввиду умышленные преобразования. Естественно, при грамотном подходе ничего страшного не случится (например, можно сделать отдельные проверки на "волшебные значения", чтобы их не затронуть).
_FR>
_FR>есть просто изменение значения переменной aka _FR>
A>>dt = dt.AddHours(hours);
_FR>
Не всегда. Например, в Московском часовом поясе для DateTime.MaxValue при переводе времени в локальное ничего не произойдёт (кроме, разве что, магии с Kind).
Здравствуйте, WolfHound, Вы писали:
C>>Например, возможность работать с локальным временем в подсистеме которая выполняется на текущей машине и завязаны на чужое API работающее с локальным временем. WH>API завязаное на локальное время это само по себе кривь жуткая. Никогда не нарывался на проблемы с переводом часов на летнее/зимнее время?
Во, вот это точно!!! Очень забавно смотреть на приложения с таймлайнами, у которых в эти два "критических" дня в году возникает либо "час Сурка" (два часа с одинаковым временем), либо час с "чёрной дырой", где времени вообще нет
Если при этом аппликуха не падает — это уже можно считать достижением!
Здравствуйте, andy1618, Вы писали:
A>Здравствуйте, WolfHound, Вы писали:
C>>>Например, возможность работать с локальным временем в подсистеме которая выполняется на текущей машине и завязаны на чужое API работающее с локальным временем. WH>>API завязаное на локальное время это само по себе кривь жуткая. Никогда не нарывался на проблемы с переводом часов на летнее/зимнее время?
A>Во, вот это точно!!! Очень забавно смотреть на приложения с таймлайнами, у которых в эти два "критических" дня в году возникает либо "час Сурка" (два часа с одинаковым временем), либо час с "чёрной дырой", где времени вообще нет A>Если при этом аппликуха не падает — это уже можно считать достижением!
Никогда не думали, что время может использоваться только как маркер в отладочных логах?
