Est-ce que quelqu'un connaît une manière plus propre d'obtenir le fuseau horaire inclus dans la représentation de chaîne ISO d'un QDateTime?
Je devrais simplement utiliser ce qui suit: P>
"2014-02-24T10:20:49" "2014-02-24T08:20:49Z" "2014-02-24T10:20:49+02:00"
3 Réponses :
Cela n'avait pas été présent avant 5.2, mais il a été intégré là-bas. Il semble que vous obteniez la syntaxe incorrecte cependant parce que cela devrait être comme ceci: selon le BugReport correspondant . Notez que tellimesPec (Qt :: offsetfromutc) appelle au milieu.
C'était la première chose que j'ai essayée. Il s'avère que, chaque fois que vous définissez le TimesPec sur QT :: offsetfromutc , il zéros sur les minutes de compensation interne. Plus tard dans l'exécution de la fonction, car le décalage est 0, TimesPec est modifié en QT :: UTC , résultant 2014-02-24T08: 23Z
Ma question initiale demande s'il existe un moyen plus propre d'obtenir l'iSodate avec la partie TimeZone incluse ou s'il s'agit d'un bogue. Vous me donnez en effet une méthode plus propre, mais cela ne me donne pas la sortie correcte, il déplace mon fuseau horaire sur UTC. Si vous obtenez la sortie correcte, je suppose que nous n'utilisons pas la même version mineure. Comme je l'ai dit, j'utilise 5.2.1. C'est peut-être un bug qui a été introduit. J'accepterai votre réponse mais je vais aussi le connecter comme un bogue avec Digia.
@ROBBIEE: Vous n'avez pas fourni de Etui de test autonome encore. Même Digia demanderait cela, je pense. Par travaux, je voulais dire que l'impression que la ligne de sortie donne un résultat correct comme prévu dans une fonction principale vide, tout comme vous semblez avoir demandé.
Mes excuses, je pensais être clair. Je vais mettre un exemple entièrement autonome montrant ce que je veux dire.
FWIW, sur un système basé sur Linux intégré, QT 5.3, cela ne résout pas le problème. Je devais utiliser une méthode personnalisée similaire à @ rudolf-cardinal réponse
Ceci semble fonctionner, avec précision de milliseconde et préservation des informations sur le fuseau horaire:
#include <QDebug>
#include <QTimeZone>
QString datetimeToIsoMs(const QDateTime& dt)
{
// An ISO-8601 format preserving millisecond accuracy and timezone.
// Equivalent in moment.js: thing.format("YYYY-MM-DDTHH:mm:ss.SSSZ")
// Example: '2016-06-02T10:04:03.588+01:00'
// Here we also allow 'Z' for UTC.
// In Qt, BEWARE:
// dt; // QDateTime(2016-06-02 10:28:06.708 BST Qt::TimeSpec(LocalTime))
// dt.toString(Qt::ISODate); // "2016-06-02T10:28:06" -- DROPS timezone
QString localtime = dt.toString("yyyy-MM-ddTHH:mm:ss.zzz");
int offsetFromUtcSec = dt.offsetFromUtc();
// FOR TESTING: offsetFromUtcSec = -(3600 * 2.5);
QString tzinfo;
if (offsetFromUtcSec == 0) {
tzinfo = "Z";
} else {
QString sign = offsetFromUtcSec < 0 ? "-" : "+";
offsetFromUtcSec = abs(offsetFromUtcSec);
int hours = offsetFromUtcSec / 3600;
int minutes = (offsetFromUtcSec % 3600) / 60;
tzinfo += QString("%1%2:%3").arg(sign)
.arg(hours, 2, 10, QChar('0'))
.arg(minutes, 2, 10, QChar('0'));
// http://stackoverflow.com/questions/2618414/convert-an-int-to-a-qstring-with-zero-padding-leading-zeroes
}
return localtime + tzinfo;
}
QString datetimeToIsoMsUtc(const QDateTime& dt)
{
QDateTime utc_dt = dt.toTimeSpec(Qt::UTC);
return datetimeToIsoMs(utc_dt);
}
QDateTime isoToDateTime(const QString& iso)
{
return QDateTime::fromString(iso, Qt::ISODate);
}
Quand j'ai besoin d'où j'utilise la solution de contournement suivante: Je n'ai pas testé si @LPappa travaille sur de nouvelles versions. La solution de contournement ci-dessus a été testée sur Qt 5.3
En outre, la sortie est différente sur ma machine, je ne peux même pas reproduire moi-même le problème exact:
"2014-02-24t08: 51: 07" "2014-02-24T08: 51: 07Z" "2014-02- 24T08: 51: 07z "La question n'a pas changé, c'est une signification, peut-être que votre compréhension de la question a changé. En bref, j'ai demandé s'il y avait une manière plus propre d'obtenir le résultat souhaité, ou si je me connecte à un bogue. Je pensais que j'étais très clair sur ça.
Quelle version de QT utilisez-vous? J'utilise 5.2.1. Le code que j'ai fourni il y a du code que j'ai en fait compilé et couru, pas simplement pensé dans ma tête. Les résultats sont des résultats réels que ma machine a généré, donc elle est qualifiée de SSCCE. Merci Laszlo pour votre contribution. Je vais marquer votre réponse comme correcte. Même si la réponse ne m'aide pas, je suppose que votre code est de savoir comment Qt devrait fonctionner et je vais enregistrer un bogue avec Digia.
Oui, j'utilise la même chose, sur Archlinux si cela compte. Je ne sais pas si cela est lié à mon fuseau horaire qui est Londres, donc pas de différence d'heures +/- heures.
Je compile sur Windows 8 mais je ne pense pas que cela ferait beaucoup de différence. Votre fuseau horaire à Londres fait une grande différence dans vos résultats car vous êtes dans UTC. Mon fuseau horaire est Sast (UTC + 2). Vous pouvez voir à partir de la sortie de test que qdateTime :: totimespec (qt :: offsetfromutc) monte mon heure locale à l'heure UTC, c'est-à-dire une heure de 2 heures plus tôt. Pour vous, le quart ne se produirait pas parce que vous êtes déjà dans l'UTC TimeZone.
Changez votre fuseau horaire Système sur "Harare, Pretoria ou Johannesburg (UTC + 2)" et retentissez votre code et vous devriez avoir les mêmes résultats que moi.
J'ai déjà essayé, mais je ne peux pas reproduire le problème personnellement.