Un fait amusant que je suis sûr que la plupart d'entre nous qui jouent à la fois dans la Time Realms savent - il y a des dattes / fois qui peuvent apparaître valables, mais n'existent pas, par exemple. 2h30, heure d'épargne de la lumière du jour.
existe une manière en C ++ (standard ou Windows) pour déterminer si une date / heure donnée est valide dans une spécification de fuseau horaire donné?
3 Réponses :
Le format TIME_T est une valeur entière (secondes depuis 1/1/1970 00:00 UTC), donc chaque valeur possible de Time_T existe (dans les limites du type entier utilisé bien sûr).
D'autre part, toutes les valeurs possibles de "struct tm" (où vous avez des membres pour jour, mois, année, heure, minute et seconde) (et c'est probablement ce que vous voulez dire). Pour vérifier si une "structure TM" existe, vous devez procéder comme suit:
Qu'est-ce que mktime est-il si vous fournissez une valeur à 02h30 lorsque vous revenez à la date normale? Le problème ici est que le délai de calendrier se répète l'heure de 02: xx deux fois (une fois avec DST et une fois sans). Si vous ne savez pas ce que vous voulez dire, l'ordinateur ne peut probablement pas vous dire non plus ...
La norme ne nécessite pas time_t pour être un entier, mais sinon il semble que la norme implique que votre solution fonctionnerait. Si cela fonctionnera réellement sur la mise en œuvre, c'est une autre question ...
@Skyking: tu as raison (partiellement). Lorsque l'horloge est réglée pendant une heure (DST -> non-DST) et que vous ne spécifiez pas si vous êtes à DST ou non, le CRT devinera, mais au moins j'espère que cela reviendrait 2: 30 DST, ou 2:30 non-DST. Quoi qu'il en soit, la meilleure façon de tester est de l'essayer. Le résultat peut en effet dépendre de la mise en œuvre du CRT.
Utilisation de cette bibliothèque libre et open source :
2016-03-13 02:30 is in a gap between 2016-03-13 02:00:00 EST and 2016-03-13 03:00:00 EDT which are both equivalent to 2016-03-13 07:00:00 UTC
Utilisation de fonctions spécifiques à Windows, vous pouvez faire un appel à À la fin, si les deux sont terminés. Un temps non valide comme tzspecificLocaltiMetosystemtime () suivi de un appel à SystemTIMetotzSpecificLocalTime () avec le fuseau horaire correspondant. tzspecificLocaltiMetosystemtime convertit le temps invalide en un temps "réel".
Une question intrigante, certainement. Avez-vous également besoin de soutenir le saut seconde jours, comme le 30 juin 2015, 23.59.60? (Si de sorte que cela exclut l'API de Google), je pense Boost Date-Time-Time-Time-Time-time serait le meilleur point de départ. J'utilise ces bibliothèques mais pas pour cette chose particulière.
J'ai marqué "Boost-Date-time" et, peut-être Nature, "Boost" puisque j'imagine qu'une solution pourrait être disponible soit disponible hors de la boîte, soit particulièrement difficile à mettre en œuvre dans ce cadre.
La bibliothèque C ++ standard est inepte à traiter avec le temps. Si vous ciblez Windows, vous pouvez utiliser SystemTIMetofileTime () ou SystemTIMetotzSpecificLocalTime (). Passage d'une mauvaise date rend la fonction échouer avec erreur_invalid_paramètre. Si cela doit être multiplate-forme, vous devez faire du shopping pour une bibliothèque.
@Hanspassant si tel est le cas, la mise en œuvre de MS est inepte dans ce cas. La bibliothèque standard C ++ a
time_t ,structure tm ,mktime etlocalTime qui devrait suffire à effectuer la tâche. Si cela ne fonctionne pas comme la prescription standard, ne blâmez pas la norme ...La bibliothèque standard C ++ est intentionnellement inepte. Il y a trop de cas de bords qui signifient qu'une bibliothèque de date générale de date tout usage ne peut pas être correctement normalisée. Le plus proche que j'ai rencontré (boost) s'appuie sur un fichier de configuration. Regardez le gâchis que Java s'est tiré de ce que Java s'est mis avec ce tout simplement terrible
java.util.date etjava.util.calendar trucs.Peut-être que Howard Hrinnant's Library est une alternative? (CPPCON Talk)
@Hanspassant donné Nous parlons des temps spécifiques TZ, je soupçonne que vous pensez à
tzspecificLocaltiMetosystemtime plutôt quesystemtimetotzspecificLocalTime . Je peux confirmer que c'est ce qui a motivé la question: il a converti un temps inexistant à une "meilleure hypothèse" d'une heure avant. Très inattendu.