Во-первых, время UTC «Ср 27 марта 06:37:40 2019 по Гринвичу» определенно верно, если рассчитывать по «Ср 26 марта 22:37:40 2019 GMT-08». Как вы думаете, это может быть 5:37?
Объяснение того, почему GMT или UTC не включают DST:
Ни UTC, ни GMT никогда не изменяются для перехода на летнее время (DST). Однако некоторые страны, использующие GMT, переключаются на разные часовые пояса в течение периода DST. Например, AKDT (летнее время Аляски) является одним из часовых поясов GMT-8 во время их летнего времени (летнее летнее время) между 10 марта и 3 ноября 2019 года. Зимой AKST (стандартное время Аляски), которое является GMT-9 используется.
blockquote>Во-вторых, как уже указывалось в другое время ответа QDateTime :: isDaylightTime
always returns false if the Qt::TimeSpec is not Qt::LocalTime or Qt::TimeZone
.Когда вы используете
QDateTime::fromString
с информацией о часовом поясе, как в примере кода , временная спецификация правильно установлена наQt::OffsetFromUTC
. Вы можете создать экземпляр другого объекта QDateTime в то же время, но с TimeSpec в виде Qt :: LocalTime или Qt :: TimeZone. Вы можете, например, преобразовать в местное время с помощью QDateTime :: toLocalTime или либо в Qt :: LocalTime, либо в Qt :: TimeZone с QDateTime :: fromSecsSinceEpoch , который принимает смещения секунд для часового пояса.См. Пример кода ниже. Я нахожусь в Финляндии, где летнее время начинается 31 марта, поэтому вы можете увидеть разницу местного времени, когда используется стандартное время и когда используется летнее время:
QDateTime time = QDateTime::fromString("Wed Mar 26 22:37:40 2019 GMT-08"); qDebug()<<"\nLocal time EET:"; QDateTime localTime = time.toLocalTime(); // This works too, here to local time: //QDateTime localTime = QDateTime::fromSecsSinceEpoch(time.toSecsSinceEpoch()); qDebug()<
Выход:
Local time EET: Qt::LocalTime QTimeZone("Europe/Helsinki") "EET" "Wed Mar 27 08:37:40 2019" "Wed Mar 27 06:37:40 2019 GMT" false Local time EEST: Qt::LocalTime QTimeZone("Europe/Helsinki") "EEST" "Sat Apr 27 09:37:40 2019" "Sat Apr 27 06:37:40 2019 GMT" true
Из Вашего сообщения кажется, что у Вас есть приложение Windows?, можно сохранить начальное значение в конфигурации приложения, можно сделать установщик в Visual Studio и записать пользовательские действия, которые могут записать значения в файл на первой установке в Вас проект установки.
Файл конфигурации является самым легким способом сделать то, что Вы спрашиваете, однако это НЕ является лучшим. На самом деле рекомендуется Не использовать .config файлы для таких случаев.
каждый раз, когда пользователи устанавливают 'обновление', существует риск перезаписи их существующих изменений.
некоторые компании могли бы иметь ограничения политики на .config файлы.
пользователь не может легко переместить свои настройки от одного ПК до другого.
На основе моего собственного опыта, с помощью XML, Доступа MS, Файлы реестра или текстовые файлы для хранения пользовательских настроек оказались более полезными, чем использование .config файлов.
Я полагаю, что Вы говорите о сгенерированных разработчиками настройках (.settings файл)?
Точный тракт обычно содержит своего рода Хеш (проверьте эту ссылку). У меня обычно есть свой собственный класс настроек, который я сериализирую к и от xml использование XmlSerializer, который дает мне больше свободы (я думаю, что файлы настроек C# не позволяют Вам добавлять пользовательские перечисления, например, или они делают его немного тяжелее, чтобы сделать это, чем простое добавление их в .settings файл).
Однако, возможно, нет никакой потребности к установленным значениям во время установки? Например, Вы могли добавить a FirstStartup
установка (набор к true
первоначально), который можно считать, когда Приложение запускается впервые и затем установило его на false
. Тем путем можно установить настройки по умолчанию при обнаружении "первого запуска".
Реестр или файл INI или XML-файл безотносительно исков Вы лучше всего.
Вам, конечно, будет нужно своего рода пользовательское действие в конце Вашего установщика. Вы не упомянули, какую технологию Вы используете для развертывания приложения, таким образом, я воздержусь от давания любых определенных указаний.
Я рекомендую установить значение в Вашем App.config
. Это - XML-файл, который назовут MyApplication.exe.config
в том же каталоге как Ваше приложение. Добавьте его к своему установщику, если это уже не там. В Вашем установщике добавьте новую установку:
<configuration>
<appSettings>
<add key="MySetting" value="My Value"/>
</appSettings>
</configuration>
В Вашем коде получите установку:
String setting = ConfigurationSettings.AppSettings["MySetting"];
Если это - установка всей машины, этот установщик является правильным местом для установки этого. Если Вы сделаете это на первом выполнении, то Вы столкнетесь с хостом проблем с полномочиями на файлах и каталогами, если первый человек, который запустит приложение, будет пользователем с ограниченными полномочиями.
Вы сказали, что это для корпоративной среды. Можно создать административный шаблон для групповой политики для установки значения по умолчанию в реестре. Затем Ваша программа может просто запросить, что один реестр оценивает, если значение по умолчанию не было уже установлено.
Наилучшим вариантом был бы реестр. Istalling приложение потребует Доступа администратора, настолько пишущего в реестр во время установки, не будет проблемой.
Больше, если кто-то случайно удаляет ini или файл настроек затем, программа могла бы прекратить работать.
Мой случай отличается, мой проект является библиотекой классов (dll), которые имеют app.config файл. Я решил создать 4 переменные параметров настройки приложения (заголовок, URL, предел, уровень). Для создания этого я щелкаю правой кнопкой по ont он проект-> Свойства-> Настройки. это оценивает Вас, может получить в коде с помощью этой команды-> Настройки. Default.title... и т.д.
проблеме позволяют, говорят, что я инстанцирую 5 объектов (тот же объект, например, MyProject. MyClass) из этой библиотеки, я хочу экземпляр смочь иметь его собственные настройки. я подразумеваю, что каждый экземпляр может иметь их xml установка файла. это может быть сделано?
Я лично никогда не стал бы использовать web.config или app.config. Просто прочтите свой собственный xml-файл, посмотрите мой пост об этом: http://www.picnet.com.au/blogs/Guido/post/2009/09/10/XML-Settings-Files-No-more-webconfig.aspx
Спасибо
Guido