I double checked my notes, and double checked the date at the time of the Dfly posting. Previously there were always 3 digits after the decimal point. When I finished the mission on mine, I checked the date, wrote it down beside the notes of the battle, and then rechecked it because there were only 2 digits after mine. I just rechecked my notes again, and it definitely said at that time of battle, .25 Therefore I figured it had skipped the 0 at the end and reported it as .250 . I suggest the .025 as that timeline fits better with the approximate time of the sequence of battles on the list. Perhaps the 0 was the first digit, as the other 2 possibilities(.250 and .205) were seemingly in the future.
Now I notice that there is only 2 digits after the decimal point since. Is there a reason for this? perhaps this is where the confusion started.
CAUTION: Hexx - do not read this long winded and probably over complicated explanation, look away now...
The kills page used to read the game server flatfile database (a relatively slow process in php) to get the server name and current server stardate and present the current server stardate with leading zeros in the decimal to fill it out to 3 digits for sorting purpooses.
I have since removed the call to read the game server flatfile database on the kills page to speed up the page load time in an effort to reduce the incidence of double posts and also becasue there were some complaints on TS about the page load time, that were mistakenly being blamed by users on lack of bandwidth.
So people are no longer being shown the current server stardate with leading zeros in the decimal place on the page so they are probably just entering it as it is normally displayed in game (without leading zeros in the decimal place).
I had manually corrected all previously entered stardates to add leading zeros to the decimal place so that they will sort properly, I have not put in the code to add leading zeros to
entered stardates where appropriate, though perhaps I should.
Here is how the Dynaverse server displays stardates in game: YearNumber.TurnNumber
So since SGO6 is configured for 365 turns per year at approximately four minute turns to provide stardates logical to Dizzy's perspective, (365 turns per year [like the days in a real year] and one year per real day) stardates on SGO6 will appear in game in the form 2265.1, 2265.2, 2265.3 ... 2265.365, 2266.1 ... etc.
I am relying on the SQL query ORDER BY clause to sort the battle reports by stardates. (hint: click the buttons in the column headers to sort by other columns
) And since in actual real value (not as a game turn) the value of 2265.25 will sort as a larger number than 2265.146 (which it is... 2265.25 > 2265.146) BUT not in terms of the game stardate where 2265.146 > 2265.25 even though the value of the float is not.
Do you see my situation here? I suppose I could modify future versions of the kills page to store the year and game turn seperately in its SQL database and use an 'ORDER BY Year,TurnNo DESC' instead of a 'ORDER BY Stardate DESC' in my SQL query... then concatenate the values as strings delimited by a period for display, though this will take some work that I'm not really willing to put into it right now. (and how to prompt the user to enter the data? as seperate values or as a standard game stardate and and split the entered float as a string delimited by a period? then add leading zeros to the turn number where appropriate? However not all servers will have the same order of magnitude in their number of turns per year and the page in intended to be generalised for all servers so I do not have to keep re-writing it... perhaps to achieve the desired effect I'll have to add some code to dtermine the order of magnitude of the turns per year and then construct the appropriate conditionals to add leading zeros to the stardate decimal where appropriate...)
Sooo.... just tell me what stardate those battles should be entered as and I'll correct them! 
Topic: Double post on the Kill Page (Read 4577 times)