Dear all, for many community projects based on the client logs, it’s a real nightmare because it is the client time instead of server time in UTC. Since we are all from many different timezone, the results are really complicated to be compared without a server side time. With a time sent by the server it would be easy to add a function in the client to adapt the ingame time with the good timezone to be shown as what we have now, but without modify the log time as server time.
Yes,good idea,the tiny player base is still scattered all around this planet(maybe other ones too)so getting one server time rather than a client time can be better since i dont want to bother with the calculations and stuff,i just want to play this horrible game and that’s it.
you make some dangerous propositions here, in the end they send the time at each packet or something just to include this 
the logs could include one starting log which indicates the current “server time”, so it would be easy to determine time difference, but having the server time on each client correct would require it to send that info over the pipe - it should be clear to you, that if you have many clients, not only the local time can be off, but also “when things happen”.
only other choice would be to use ticks instead of time, but thats not nice for anyone actually reading those logs.
___
but with a new line in the log your problem could be simplified. things like battle instance id etc. are also nice things to have if you combine multiple logs.
this new information packet could btw. also include the ingame username, corpname, etc. so its easier to parse these things for users without steam, where until now i had to guess the username by parsing forward until the first match - but i am not sure if this is still an issue, i just remembered that this was one of my issues.
Actually, server events are sent to the client and could be included with the server timestamp. I know that unfortunately there is a lot of things that are client sided in Star Conflict (and is a real security issue for who know how to decompile the game) but the fact that the client time in log is the host time may be an issue for services like killboard based on time event. If someone for example send a log with 5 to 10 minutes of late it will be an issue. If we have UTC and sync time between the log and the server time, it’s fixed like forever. I’m 100% positive that it will not ask more resources if it’s properly coded and would really helps. I had to create so much functions to prevent any time issues that it could be really nice to have that UTC server time 
including the time in every event is a lot of network traffic. just imagine all the combat log events.
most of the work in a game engine on network side is to reduce every single byte you send. having the time of the server in every RPC, is completely useless.
you could of course - as i said - send the time at the start. either log it - there might even be some base packet which actually does let you know the time.
or maybe even redo the logging engine, so it uses the server time (estimated).
being hopefully some kind of state-machine, the game engine probably could also log “ticks”, which are most likely unique and are based on the server time. much like the unix time code.
but… as long as its a client log, logging client events, any event will have the timestamp of when it happened on the client, or arrived to the client.
and there is no such thing as 100% sync. i am writing network protocols quite often, so believe me.
if such information as server logs are interesting, it would be easier to have that in an api.
i know what you mean, but i tell you, you could have the same information, if the server time - or any common id that is unique - is logged. it will never be wise to simply assume two separate logs mean the same thing, just because of timecodes, and you will always have some “exceptions”.
and i have done parsing SC logs aswell - actually i parse every single packet exactly - and also brainstormed about “bringing them together”, so exactly the same idea as you had, so i know exactly where your problem currently lies and so i think its a good idea, to have more markers in the logs for you to be able to stick them together (and also determine if logs can be trusted, or other events; basicly what you could do easy if you had server logs)
but exactly this is why i warned about wisdom; I might understand your case and know how to do it right, you might know how to do it right, but u know…
also note, i do not know the actual code. so maybe they already include the timestamp anyway - not the first time i would have seen that
then your request would be easy.
but i bet its actually not included, and the timestamp it gets is upon receival.
probably its not even packet information, but only added directly at the log function.
in any case, if you would have an estimated server time packet log at the start, you could build your “server time” yourself after parsing, what i am saying.
it would not be any more correct, than writing the server time “estimated” based on local time in the log function anyway.
and it would be horrible, if they include a timecode in every packet, if they did not do so until now, just for the logs
in this case silmerias, i had another thought you might be able to share your thoughts on, thats personal events in the logs:
user events which are only available on the client - usually starting with the client user - such as trophies awarded or similar (“earned medal …”) - could get their own PACKET id, so they would be easy to recognize apart from the general game events.
the “official” battle log, would be a (set of all logs) - (set of all client logs)
and basicly, that would mean, if you would compare logs from many users, you could reduce it to the same amount of packets and it would be in the same order.
atm. they dont have a common id to recognize them.
did you encounter a similar thought?
What about to have two time values then? Client time and server time in UTC.