Discussion :

[hihaho74]

Bonjour,

Je rencontre un problème avec une fonction array_replace qui jusque-là fonctionnait correctement. Et je ne vois pas mon erreur...

Dans la gestion d'un calendrier, je forme une variable $BASE = array();. Je la remplis pour les 6 prochains mois avec des données "blanches" (toutes les mêmes).

Puis je crée une nouvelle variable $OCCUP = array(); que j'alimente avec une base de données mysql.

Ensuite je mets à jour $BASE avec les données de $OCCUP pour former $CALENDRIERVoici les résultats visualisés avec var_dump() où je mets en valeurs (gras) les données qui sont bien passées... et en couleur (rouge) celles qui se sont bousculées...


// array CALENDRIER (extraits : tout est comme ça sur 6 mois)
46 => string '2024-03-22:lib:White:id-x' (length=25)
47 => string '2024-03-23:lib:White:id-x' (length=25)
48 => string '2024-03-24:lib:White:id-x' (length=25)
49 => string '2024-03-25:lib:White:id-x' (length=25)
50 => string '2024-03-26:lib:White:id-x' (length=25)
51 => string '2024-03-27:lib:White:id-x' (length=25)
52 => string '2024-03-28:lib:White:id-x' (length=25)
53 => string '2024-03-29:lib:White:id-x' (length=25)
54 => string '2024-03-30:lib:White:id-x' (length=25)
55 => string '2024-03-31:lib:White:id-x' (length=25)
56 => string '2024-04-01:lib:White:id-x' (length=25)
57 => string '2024-04-02:lib:White:id-x' (length=25)
58 => string '2024-04-03:lib:White:id-x' (length=25)
59 => string '2024-04-04:lib:White:id-x' (length=25)
60 => string '2024-04-05:lib:White:id-x' (length=25)
61 => string '2024-04-06:lib:White:id-x' (length=25)
62 => string '2024-04-07:lib:White:id-x' (length=25)
63 => string '2024-04-08:lib:White:id-x' (length=25)
64 => string '2024-04-09:lib:White:id-x' (length=25)
65 => string '2024-04-10:lib:White:id-x' (length=25)
66 => string '2024-04-11:lib:White:id-x' (length=25)
67 => string '2024-04-12:lib:White:id-x' (length=25)
68 => string '2024-04-13:lib:White:id-x' (length=25)

Le changement de mois (bleu gras) se fait bien


// array OCCUP (extraits)

...
48 => string '2024-03-24:oui:#DF0101:1217' (length=27)
54 => string '2024-03-30:bleu2:#FE2E2E:1208' (length=29)
55 => string '2024-03-31:bleu2:#FE2E2E:1208' (length=29)
58 => string '2024-04-04:bleu2:#DF0101:1216' (length=29)
59 => string '2024-04-05:bleu2:#DF0101:1216' (length=29)
64 => string '2024-04-10:oui:#FE2E2E:1214' (length=27)
65 => string '2024-04-11:oui:#FE2E2E:1214' (length=27)
66 => string '2024-04-12:oui:#FE2E2E:1214' (length=27)
...

// array CALENDRIER résultant de
// $CALENDRIER = array_replace($BASE, $OCCUP);

48 => string '2024-03-24:oui:#DF0101:1217' (length=27)
49 => string '2024-03-25:lib:White:id-x' (length=25)
50 => string '2024-03-26:lib:White:id-x' (length=25)
51 => string '2024-03-27:lib:White:id-x' (length=25)
52 => string '2024-03-28:lib:White:id-x' (length=25)
53 => string '2024-03-29:lib:White:id-x' (length=25)
54 => string '2024-03-30:bleu2:#FE2E2E:1208' (length=29)
55 => string '2024-03-31:bleu2:#FE2E2E:1208' (length=29)
56 => string '2024-04-01:lib:White:id-x' (length=25)
57 => string '2024-04-02:lib:White:id-x' (length=25)
58 => string '2024-04-04:bleu2:#DF0101:1216' (length=29)
59 => string '2024-04-05:bleu2:#DF0101:1216' (length=29)
60 => string '2024-04-05:lib:White:id-x' (length=25)
61 => string '2024-04-06:lib:White:id-x' (length=25)
62 => string '2024-04-07:lib:White:id-x' (length=25)
63 => string '2024-04-08:lib:White:id-x' (length=25)
64 => string '2024-04-10:oui:#FE2E2E:1214' (length=27)
65 => string '2024-04-11:oui:#FE2E2E:1214' (length=27)
66 => string '2024-04-12:oui:#FE2E2E:1214' (length=27)
67 => string '2024-04-12:lib:White:id-x' (length=25)
68 => string '2024-04-13:lib:White:id-x' (length=25)
69 => string '2024-04-14:lib:White:id-x' (length=25)

Jusqu'au 31 mars tout va bien.

Puis le 1er avril (jour du poisson éponyme !!!) ça déraille :

si la clé 57 est encore bonne avec la date 2024-04-02, la clé 58 qui devrait être datée 2024-04-03 se voit attribuer une date 2024-04-04 alors que dans $OCCUP elle avait bien la date 2024-04-03

Je ne comprends pas, et j'ai passé pas mal de temps ce WE pour ajuster au niveau des clés.
Si je veux que ça marche à partir du 1er avril... il suffit que j'augmente la clé de 1 quand je fais le foreach qui crée l'array $OCCUP mais dans ce cas les dates de mars sont fausses et se retrouvent en décalage.

Pour info, le while sur le tableau mysqli puis la boucle for fabricant $OCCUP :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
// depuis la requete mysqli
    while($r = mysqli_fetch_array($req))
        {
        $arr = $r['arrive'];
        $max = $r['nnuits'];
 
/* puis j'attribue une donnée d'ensemble de la réserve en cours
    if($cl == 1){$col = "#DF0101"; $cl++;}else{$col="#FE2E2E"; $cl=1;}
*/
 
// enfin je mesure le nbre de jours séparant $arr depuis aujourd'hui ($dhuip)
    $diff = (strtotime($arr) - strtotime($dhuip))/86400;
    $key = $diff;
 
for ($t = 0; $t< $max; $t++)
{
    $ndate = date('Y-m-d', strtotime($arr. ' + '.$t.' days'));
    $clef = (int)$key;
    $value = $ndate.":".$r['valid'].":".$col.":".$r['id'];
    $OCCUP[$clef] = $value;
    $key++;    
}
// mon array $OCCUP est maintenant correct avec comme origine de clé le aujourd'hui ($dhuip) comme ce qui a fait $BASE par ailleurs

J'espère m'être exprimé clairement...
Quelqu'un aurait-il une idée sur ce mystère en dehors d'un poisson d'avril (car cela continue ainsi -décalage de dates- jusqu'en novembre )
Merci beaucoup d'avance pour vos efforts

[mathieu]

que contient $dhuip ? aujourd'hui à minuit ? aujourd'hui à l'heure actuelle ?

[xor AX AX]

Heure d'été dans la nuit du 30 au 31 ?

[hihaho74]

Merci xor AX AX

Heure d'été dans la nuit du 30 au 31 ?

Il est bien possible que ce soit ça. Je viens d'inscrire des dates en novembre et elles ne buguent pas. Mais ça fait deux ans que ce calendrier fonctionne... et sans problème !!!
Je regarde ça demain matin et je viendrai ici pour confirmer ou infirmer !

A plus, gardez le fil.

[xor AX AX]

2024 année bissextile. Mais ton bug aura 1 mois de retard :-)

[unanonyme]

je me disait qu'on se serait évité le problème en utilisant la date du jour pour indexer les objets.

[ProgElecT]

Salut
À une époque où je relevais 5 données météo toutes les 10 minutes 24 heures sur 24, indexé jour/heure, tout ça en jour et heure local.
Au bout de 3 ans, patatras, année bissextile ainsi que perte de données de 2 jours par an en dut au passage heure d'été /hiver.
La solution, indexer jour/heure GMT.

[hihaho74]

2024 année bissextile. Mais ton bug aura 1 mois de retard :-)

Tu pourrais avoir raison xor AX AX, mais pour ça je m'appuie sur dernier jour du mois = cal_days_in_month(CAL_GREGORIAN, $mois, $an); ce qui ne cause pas d'erreur sinon mars aurait aussi une erreur au cas où je n'aurais pas pris en considération les années bissextiles.

Après avoir essayé de voir comment reprendre la structure des données de l'array() en jouant sur les dates , je bute forcément sur le fait que les clé sont responsables (pourquoi ? Mystère...).

Aussi selon la suggestion de unanonyme et ProgElecT que je remercie chaleureusement, j'ai commencé à réviser mon code en prenant clé la date qui est unique puisqu'elle ne couvre qu'une seule valeur

Je vais donc considérer ce sujet comme résolu (mais je le laisse encore jusqu'à demain si l'un ou l'autre d'entre vous a quelque chose à dire)

[xor AX AX]

Je développe actuellement la v2 d'une application qui peut ressembler à la tienne.

Dans ce cas, mon API PHP ne gère que :

1. l'authentification (mais ça reste à faire)
2. l'envoi et la récupération de data sur les tables de ma base de données
3. la mémorisation dans une table et dans $_SESSION du stamp (horodatage) des tables modifiées
4. un 2ème script SSE qui analyse les stamps (table comparée à $_SESSION) pour déclencher l'envoi de données aux clients JS

Mon PHP ne doit recevoir (j'ai encore du boulot à faire) que de l'UTC. Ce n'est pas à lui de faire le job de la localisation.

Mon client JS fait le reste, comme gérer les locales date/time et donc n'envoyer au PHP que de l'UTC.

[unanonyme]

pour moi c'est la conclusion de ce post, toujours travailler en UTC, toujours travailler en utf-8.
Les localisations, les encodages, ça se gère en bout de chaîne.