Я так понимаю, вы с ним работаете из реального приложения, и все моменты переходов на летнее/зимнее время он у вас сохраняет и загружает как положено? Речь ведь не о поддержке часовых поясов, речь о том, чтобы гарантировано сохранить/загрузить одну и ту же дату в условиях смены зимнего/летнего времени. Если это так (если вы это _проверяли_), то я готов признать свою ошибку, если вы просто хотите ткнуть носом в документацию, которую я и так видел, что ж, спасибо, что помогли как сумели.
Думаю, универсального времени не будет, так как если планеты движутся друг относительно друга, то время на них течет с разной скоростью. А вообще вопрос очень интересный, гораздо интереснее, чем на одной планете время синхронизировать.
Мнээ, зачем, говорите, программисту знать о том, что GMT is deprecated? Чтобы прикидываться осведомленным? А високосную секунду не только 31-го декабря прибавляют, но еще и 30 июня. Плюс, все разглагольствования находятся в секции бонус, так что я и не претендую на то, что это необходимо знать программистам. Это скорее стимул пойти почитать, пускай даже для 2% интересующихся.
И мне кажется, что суть статьи от вас все-таки ускользнула: я попытался объяснить, почему удобно пользоваться UTC, а не сухой набор фактов для запоминания.
Ну не соглашусь, эта статья из шишек набитых родилась в основном, пока такого вот ясного понимания не было, у нас постоянно энтузиасты во всех местах где только можно переводили из пояса в пояс (причем какими-то джедайскими методами, натурально прибавляя/отнимая часы), хранили флаг летнего/зимнего времени, подгоняли, долго не могли вкупить, что это за время отображается, и опять прибавляли/отнимали часы (чисто на глазок: а, ну тут примерно разницу между местным и московским прибавить? прибавим), вели две колонки: время местное и время московское и т.д.
А имея хорошее понимание того, как обстоят дела, можно и другие системы работы со временем осваивать (в других языках, например), и не путаться (что, на мой взгляд, главное).
Да, точно, что-то я на Джавную реализацию засмотрелся, а они еще и миллисекунды считают. В unix timestamp миллисекунды дробями идут, если нужно. Спасибо.
В 1.4.2, что ли, у них тег wicket:enclosure тупо не работал. То есть вообще. Минорный, потому что вторая цифра называется минорным номером версии.
Я о том и говорю, если совместимости все равно нифига нет, ради чего внутренности-то прятать? Получается, только ради того, чтобы жизнь усложнить.
Поймите, библиотека — это инструмент, и нужна она для одной цели — чтобы люди ей пользовались и она приносила им пользу, помогала решать их задачи. Поймите также, что никто никогда не предугадает всех возможных вариантов использования. Лучшее, что может библиотека — помочь тем, чем может, и не мешать в остальном. Если миссия библиотеки — облегчить жизнь создателю/мейнтейнеру, или научить, как жить пользователям, то нафиг такую библиотеку.
В случае с Викетом, например, получается, что их цель — обеспечить пользователям плавный переход между релизами (у них не получается, но в идеале). Но нет такого пользователя, которому был бы интересен плавный переход на новую версию. Есть пользователи, которым интересно, позволяет библиотека сейчас решить их проблему или нет. Если ответ «почти», то лучше пусть они ее доточат, чем выкинут, не?
Да, они этим оправдываются, но на деле даже внутри багфикс-релизов ее умудряются ломать, я уж не говорю про минор (одно переименование getModel → getDefaultModel чего стоило). Видимо, для них совместимость все-таки несущественна.
если они что-то не сделали частью публичного api, то на то были причины.
Как раз наоборот, им нужны причины, чтобы что-то сделать частью публичного апи. На деле же оказывается, что они совсем не так дальновидны, как им кажется. И вот тут я бы с удовольствием сам решал проблемы с совместимостью (натурально, правил бы свой код, реши мы проапгрейдить версию), чем имел бы возможность безболезненно переходить на новую версию. Как-то новые версии меня не очень греют, а вот задачи, которые я не могу решить сейчас, все-таки напрягают.
Так с ней ничего не случилось, есть она, инкапсуляция, просто ее с одного уровня на другой перенесли. Или вы думаете, что вот есть инкапсуляция, и все сразу поумнели и начали ее по делу использовать? О том, какой вред она может наносить в кривых руках, не задумывались?
У меня вот, из наболевшего, Wicket Web Framework — все внутренности закрыты железобетонно, и что, думаете, хорошо это? А я вот постоянно плачу, что-то в принципе не расширяется, у чего-то, чтобы расширить, приходится тупо реализацию из исходников копировать и менять, потому что нихрена в классе поменять не могу — инкапсуляция. Это ваше светлое будущее, за которое стоит бороться?
Все рассуждения про инкапсуляцию хороши, пока дело не доходит до реальных ситуаций. Из двух зол — похакать исходник библиотеки либо вообще не реализовать функциональность вы предлагаете выбрать второе решение как более «правильное»? Не кажется ли вам, что стоит оставить этот выбор все-таки программисту и дать ему решать в каждом конкретном случае?
А соображение, что инкапсуляцию на уровне языка не ввели потому, что она там не нужна, вам в голову не приходило? Что иметь ее на уровне соглашений — решение более гибкое? Убрать, например, ее всегда можно (think java→groovy), а добавить так легко нельзя, потому что ее отсутствие дает программисту больше возможностей, чем наличие?
У нас тут в программерской конторе такую политику пытались применять. Только еще и с антивирусом в довесок. Админ молодой, неопытный, начальству пофиг. Понятно, собрали все подводные камни как по нотам, сейчас в итоге плюнули и всем выдаются админские права. Апокалипсиса не случилось, но и пользователи более-менее ответственные, конечно.
Есть еще такой фильм Sleuth (Ищейка), там в начальных титрах трех актеров перечисляют, а в итоге их в фильме оказывается всего два. Отличная уловка «для умных», на мой вкус.
Блин, ну ведь круто же. Правда, мне больше хочется, чтобы по клику на картинку открывалась полноразмерная версия картинки, но на это, как известно, придется userscript вешать.
И мне кажется, что суть статьи от вас все-таки ускользнула: я попытался объяснить, почему удобно пользоваться UTC, а не сухой набор фактов для запоминания.
А имея хорошее понимание того, как обстоят дела, можно и другие системы работы со временем осваивать (в других языках, например), и не путаться (что, на мой взгляд, главное).
Я о том и говорю, если совместимости все равно нифига нет, ради чего внутренности-то прятать? Получается, только ради того, чтобы жизнь усложнить.
Поймите, библиотека — это инструмент, и нужна она для одной цели — чтобы люди ей пользовались и она приносила им пользу, помогала решать их задачи. Поймите также, что никто никогда не предугадает всех возможных вариантов использования. Лучшее, что может библиотека — помочь тем, чем может, и не мешать в остальном. Если миссия библиотеки — облегчить жизнь создателю/мейнтейнеру, или научить, как жить пользователям, то нафиг такую библиотеку.
В случае с Викетом, например, получается, что их цель — обеспечить пользователям плавный переход между релизами (у них не получается, но в идеале). Но нет такого пользователя, которому был бы интересен плавный переход на новую версию. Есть пользователи, которым интересно, позволяет библиотека сейчас решить их проблему или нет. Если ответ «почти», то лучше пусть они ее доточат, чем выкинут, не?
если они что-то не сделали частью публичного api, то на то были причины.
Как раз наоборот, им нужны причины, чтобы что-то сделать частью публичного апи. На деле же оказывается, что они совсем не так дальновидны, как им кажется. И вот тут я бы с удовольствием сам решал проблемы с совместимостью (натурально, правил бы свой код, реши мы проапгрейдить версию), чем имел бы возможность безболезненно переходить на новую версию. Как-то новые версии меня не очень греют, а вот задачи, которые я не могу решить сейчас, все-таки напрягают.
У меня вот, из наболевшего, Wicket Web Framework — все внутренности закрыты железобетонно, и что, думаете, хорошо это? А я вот постоянно плачу, что-то в принципе не расширяется, у чего-то, чтобы расширить, приходится тупо реализацию из исходников копировать и менять, потому что нихрена в классе поменять не могу — инкапсуляция. Это ваше светлое будущее, за которое стоит бороться?
Все рассуждения про инкапсуляцию хороши, пока дело не доходит до реальных ситуаций. Из двух зол — похакать исходник библиотеки либо вообще не реализовать функциональность вы предлагаете выбрать второе решение как более «правильное»? Не кажется ли вам, что стоит оставить этот выбор все-таки программисту и дать ему решать в каждом конкретном случае?