Chechnya: Так это не у меня одного, а еще и у десятка участников)
Ну вот и напишите десяток сообщений каждому.
Из админки вы это не исправите точно. Могу посоветовать заказать услугу, но вы сочтете это издевательством.
Движок перешл на зимнее время автоматом, убрал галочку в админке "корректировка времени зимнее/летнее", а часы не поправляются на час вперед обратно...+3 Москва, кстати здесь на форуме та же проблема)
если внимательно почитать, то становится ясно, что эта настройка действует для незарегистрированных. Разлогиньтесь и убедитесь.
А пользователи сами себе себе выставляют в профиле свои настройки. Вот и здесь вы вместо автоматического перевода, который работает правильно, выставили что-то свое.
Тоже, в общем-то, можно исправить настройку для всех пользователей немного изучив как хранятся эти данные в базе.
[umka: ;9602713]Как не надо? Тоже надо, он как и пхп содержит свою базу таймзон.
Может содержать, но многим это не нужно. По крайней мере в чистых инсталляциях на убунту и centos эти таблицы есть, но они пустые.
Тут вопрос в том нужны ли вам вообще эти сложные вычисления в разных таймзонах одновременно. В большинстве случае mysql будет прекрасно работать с системной базой.
теперь следующий тезис : в задачах для которых создан nginx, число клиентов ЗНАЧИТЕЛЬНО превосходит количество процессоров ( по крайней мере, значительней чем обычно в субд/вебсерверах/десктопных программах), а значит расходы на обмен и диспетчеризацию тоже будут значительными.
Тут не надо пытаться распараллелить, чтобы нагрузить второй процессор - он и так нагружен другими клиентами.
Просто логично что если процессы можно выполнить параллельно их надо выполнять параллельно
если можно создать себе дополнительных сложностей - их нужно создать.
офигеть как логично.
netwind добавил 29.10.2011 в 20:11
babnicks: И что? А какие расходы на синхронизацию в описываемом мной подходе? Вы их считали?
это то, что полностью скрыто от десктопного программиста разнообразными абстракциями и библиотеками.
не могут две нити просто так обменяться данными. каждая должна убедиться , что другая не ведет запись или чтение одну и ту же область памяти для обмена. тут и получается, что одна нить ожидает другой. при сложном взаимодействии подобные инциденты накапливаются и потери времени на ожидание становятся ощутимыми.
Chechnya, так зачем в админке, когда можно через форум?
Так это не у меня одного, а еще и у десятка участников)
Ну вот и напишите десяток сообщений каждому.
Из админки вы это не исправите точно. Могу посоветовать заказать услугу, но вы сочтете это издевательством.
Движок перешл на зимнее время автоматом, убрал галочку в админке "корректировка времени зимнее/летнее", а часы не поправляются на час вперед обратно...+3 Москва, кстати здесь на форуме та же проблема)
если внимательно почитать, то становится ясно, что эта настройка действует для незарегистрированных. Разлогиньтесь и убедитесь.
А пользователи сами себе себе выставляют в профиле свои настройки. Вот и здесь вы вместо автоматического перевода, который работает правильно, выставили что-то свое.
Тоже, в общем-то, можно исправить настройку для всех пользователей немного изучив как хранятся эти данные в базе.
Но это какая-то MySQLi
эта настройка используется для обеих библиотек и mysql и для mysqli.
нужно было с самого начала ее раскомментировать.
Теперь надо чинить.
Возможно, это уже нормальное отображение?
точно нет.
Смотрите крутилки от CodeCanyon талантливейшее кодеры
че прям КАЖДЫЙ ? это при том, что там можно зарегистрироваться и продавать свое говно
http://codecanyon.net/wiki/selling/author-selling/author-program/
TC посмотрите на openx. там есть почти все что можно нафантазировать.
Konstantin_S, зачем еще один ? в php все равно по-настоящему не работает fastcgi.
А что, опция "определять летнее/зимнее время автоматически не работает" ? У меня работает.
;9602713]Как не надо? Тоже надо, он как и пхп содержит свою базу таймзон.
Может содержать, но многим это не нужно. По крайней мере в чистых инсталляциях на убунту и centos эти таблицы есть, но они пустые.
Тут вопрос в том нужны ли вам вообще эти сложные вычисления в разных таймзонах одновременно. В большинстве случае mysql будет прекрасно работать с системной базой.
babnicks, Ну вот.
теперь следующий тезис : в задачах для которых создан nginx, число клиентов ЗНАЧИТЕЛЬНО превосходит количество процессоров ( по крайней мере, значительней чем обычно в субд/вебсерверах/десктопных программах), а значит расходы на обмен и диспетчеризацию тоже будут значительными.
Тут не надо пытаться распараллелить, чтобы нагрузить второй процессор - он и так нагружен другими клиентами.
Вы перешли в режим "веры"
вы из него и не выходили, если считаете параллельное программирование необходимой вещью и пытаетесь придумать где бы его можно еще использовать.
если можно создать себе дополнительных сложностей - их нужно создать.
офигеть как логично.
netwind добавил 29.10.2011 в 20:11
И что? А какие расходы на синхронизацию в описываемом мной подходе? Вы их считали?
это то, что полностью скрыто от десктопного программиста разнообразными абстракциями и библиотеками.
не могут две нити просто так обменяться данными. каждая должна убедиться , что другая не ведет запись или чтение одну и ту же область памяти для обмена. тут и получается, что одна нить ожидает другой. при сложном взаимодействии подобные инциденты накапливаются и потери времени на ожидание становятся ощутимыми.
нет обмена данными - нет ожидания, есть nginx.