I have a service where messages may be created (and put in a "send" queue) even when there's no connection to the server. When the messages are sent to the server after successfully connecting, should the "message sent time" be set when the server got the message or when it was actually composed by the user?
Letting the client determine the timestamp seems open to abuse. How do you know the user's clock is set correctly? Gizmodo claims that 1.9% of Android devices are 1 hour fast, and not just for innocuous reasons:
Coin Dozer is styled as an old-style fair/arcade game in which coins are pushed onto a table where they can bump other coins off into a collection tray. The user starts with a finite number of coins, more coins can be won to continue playing, additionally every 30s a coin is generated. If all coins run out by falling off the wrong side, the user must wait for a coin to be generated. This is a cunning technique to encourage users to keep the app open, which will increase ad revenue for the creators.
A cheat was discovered on Android and iOS that involves manually advancing the system clock to fool Coin Dozer and gain coins more rapidly. Since the system time on both iOS and Android is altered by scrolling through numbers, the quickest adjustment is to alter the clock by one hour, one day, or one minute. The cheats generally recommend an hour or a day in order to generate a full complement of coins.
If the messages being sent are in any way time sensitive, can be gamed, or has anything to do with finances, you can only rely on the time the server received the message. If the messages are just harmless bits of text, it may be safe to use the queued time. Just keep in mind that times won't be entirely accurate.
It is worth noting that email clients do not count messages as being "sent" until they have been successfully delivered to the mail server.
I think the "sent time" should be the time it was sent from the server - that is the actual time of transmission. It doesn't make sense to me to set the sent time to the time the message was created and saved by the user because the user never actually sent it - in the offline case.
It feels a little like when you purchase something that needs to be shipped to you. Generally, the shipper doesn't send you the "we've shipped your package" until it has actually shipped their location. They wouldn't send that message when they pull your product off the shelf or even received the invoice.
Indicate the time of the handoff: When the client delivered the message to the server for processing (regardless of whether the server then took seconds or days to get the message to the recipents).
What you describe sounds like the Outbox of an e-mail client. If the client is holding a message in a queue (e.g., waiting for network connectivity or a certain time of day before transmitting to the server), then that message has not been sent. It makes no sense to use "time when I finished typing the message" as the final sent timestamp.
Your interface should clearly differentiate between pending messages (e-mail's Outbox) and sent messages (e-mail's Sent Items). You may also wish to show the "time when I finished typing the message" while it is in the pending/queued state (or you may wish to simply show "Pending" without a timestamp), but you should definitely show the transmission time once the message has been given to the server for processing.
tl;dr: Time sent is when the client has completed its responsibilities.
Send time should be the time service add messages to the send queue. Nothing else. If you have performance issues on the server, it should be solved technically.
You should also measure the time difference between added to queue and servers actual send time. If this time exceeds to hours, you have a problem.
Imagine a queue for receiving updates on available apartments. If you let the server time rules and you have two users getting the same message and with different time stamps. If these users talk to each other, there will be confusion and your system won't be trusted.
Use the sending time, and not the server sending time. Solve your performance issues in the sending message server.