Histoire de dates

[lyaak]

bonjour

je suis revenue sur Atys il y a peu, et ai remarquer que la date du jour donné sur l'encyclopatys (en bas a gauche) n'est pas bonne. après recherches j'ai trouvé http://fondation.bourdu.org/time.htm
mais voilà je me pose des questions puisque la date donnée pour l'event de ce soir est le 20 pluvia-II alors que d'après le site on est au troisième cycle et non au second.

[edit] il semble en éffet qu'il y ai juste une petite erreur, l'event d'hier était bien au CA 3

[kervala]

De toute façon, personne n'a la date correcte estimée :s Le seul truc qui est sensé être bon, c'est la date du moment présent

[cedrigo]

Le petit soft de la fondation est assez fiable.

J'ai fait un test sur des événements lointains (2004) dont j'avais la date précise et des luciogrammes, et le convertisseur m'a donné la bonne année et la même saison que celle des lucios. Je doute qu'on puisse avoir une précision au jour près, mais la saison c'est déjà super.

A ce propos, si quelqu'un a conservé des screenshots du 20 sept 2004 (posté sur un forum ou autre) et qui indiquent la saison clairement, ça m'aiderait beaucoup pour un event futur (anniversaire). Etant dans les lacs à l'époque la saison n'est pas facile à identifier, alors si vous étiez en jungle ou forêt...

Merci d'avance

[kervala]

Oui j'ai même viré le mien vu que celui de Prysma est mille fois mieux

Il tient compte de plusieurs dates passées pour avoir une conversion la plus précise possible.

[netto]

Oh un nid de kitin là !
*tousse* pardon je me suis perdu dans mes pensé... quel heure est il au juste ... oh 4e CA à ma montre ! mon dieu mon dieu elle est cassé ? *secoue la montre* bah c'est pas grave 2eme 3eme ou 4eme CA quel importance au final !

[houlecorn]

Oui le machin à Kotaro marche bien, c'est à dire au moins pour des dates pas trop éloignées de la date actuelle...
Ça repose - si je peux me permettre - sur une interpolation linéaire qui donne la date grâce au coefficient secondes atysiennes/secondes réelles (appelé BDT dans le script de Kotaro) et un repère facile (tick 0 <=> 30 Pluvia, 4e CA 2524, 00h00).

C'est à dire que ça marche bien, tant qu'on n'éteint pas le serveur, puisque les dates atysiennes évoluent paralèllement à son uptime.

Donc ce script ne marche pas sur de longues durées, plus particulièrement avant la reprise (oct 2008). Il faudrait donc au lieu d'une interpolation en établir plusieurs grâce à des dates repère, et sélectionner la bonne en fonction de la date choisie... Ce qui devrait donner un résultat acceptable en-dehors des périodes de serveurs éteints. Avec des données de dates précises comme repère, ça peut faire des très bons résultats.

En tout cas sans toute cette usine à gaz j'ai transformé un peu le script de Kotaro pour en faire des fonctions utilisables en PHP, histoire de pouvoir utiliser ça sur le site de tout un chacun, et ça donne ça :
http://lucjaulmes.free.fr/calendrier_php


Qui peut s'utiliser comme on veut...

Code: Select all

<?php
include('calendrier.php');

function temps_restant_saison()
{
	// On veut savoir le mois actuel (1 à 12)
	$mois = atysdate('n');
	
	// On en déduit le prochain changement de saison
	while(++$mois % 3 != 1);
	// NB le mois n°13 a bien un sens pour atystime
	
	$changement = atystime(1,$mois);
	$restant = $changement - time();
	
	echo 'Il reste ',floor($restant/(24*3600)) ,'j ', floor(($restant/3600)%24),'h ',floor(($restant/60)%60),'m ',($restant%60),'s irl avant la prochaine saison ('.constant('SAISON_'.floor(($mois%12)/3)).').';
	// exemple : Il reste 2j 0h 19m 50s irl avant la prochaine saison (Été).
}

$params = 'd,D,j,l,S,w,z,F,m,M,n,t,C,k,K,Y,y,a,A,g,G,h,H,i,s';
$test = array_combine(	explode(',',$params), explode(',',atysdate($params)) 	);
echo '<p>On est à cet instant le ' .$test['l'],', ',$test['F'],' ',$test['j'], ', ', $test['C'], 'e CA ', $test['Y'], ', il est ', $test['H'], ':', $test['i'], ':', $test['s'], ' et la saison est le ',$test['K'],'.</p>';
// exemple : On est à cet instant le Holeth, Germinally 18, 2e CA 2545, il est 10:11:46 et la saison est le Printemps.
?>

[houlecorn]

Voilà, j'ai corrigé un peu http://lucjaulmes.free.fr/calendrier_php et en ajoutant à côté http://lucjaulmes.free.fr/goodtimes_php on obtient des dates correctes dans le passé.

[netto]

En effet le problème viens du faite que lorsque le serveur est arrêté, le temps IG (Tick) est lui aussi arrêté alors que le temps IRL, lui, continue de s'écouler. Ceci provoque alors un glissement des couples dates IRL/IG passés lors du calcule.

Exemple (non concret) :
imaginons que le "16 janvier 2009" corresponde au "16 Thermis 3eme CA 2547"
Si le serveur de redémarre pas depuis cette date, le calcule linéaire devrait donner le même résultat.
Mais si le serveur a eu 1 journée d'arrêt le 1 mars par exemple, le glissement des dates donnera alors un décalage d'une journée IRL lors du recalcule de la date passé. Soit "17 janvier 2009" = "16 Thermis 3eme CA 2547"

C'est en effet le point faible. Malheureusement ce glissement entre les dates IRL/IG n'est pas calculable linéairement. Pour cela il aurait fallu prendre en compte tout les dates d'arrêts du serveurs ainsi que leurs durée depuis le lancement. Sans compter qu'il faudrait remettre le programme à jour à chaque nouvelle arrêt du serveur (et ca c'est vraiment trop contraignant).

Une autre methode consisterai a créer dynamiquement une base de donnée avec une référence date IRL/IG journalière afin de limiter de beaucoup le défaut de recalcule. Mais pour cela il faudrait une base central sur un serveur (ce qui n'était pas possible en Vbscript). Mais même ainsi, ceci ne serait vraiment efficace qu'a partir de sa mise en production. Reste que pour les dates passées cela resterait toujours aléatoire puisque les couples de dates de référence IRL/IG n'existent pas pour chaque jour écoulé avant la mise en production du système de référencement journalier.

Enfin bref, beau travail pour la convertion en PHP

[houlecorn]

Il explique bien le Tryker... De toute façon la solution la plus simple est de prendre comme convention que tout le monde arrête sa montre quand le serveur est down. Comme ça le temps réel et le temps atysien adhèrent comme il faut.

Sinon, en notant régulièrement dans les données du goodtimes le coupe date irl/ig (ce qu'on pourrait faire automatiquement toutes les n synchros par exemple) on obtiendrait des valeurs très exactes de dates à intervalles réguliers... donc des approximations plutôt raisonnables pour les glissement de dates.

[ulukyn]

Pourquoi ne pas recupe le tick serveur des logs et l'envoyé via une requete a un site web?

Ce qui permettrai de mettre à jour regulierement les couples dates ig/irl.