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?
0
Add a comment
|
5 Answers
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'll probably use server time for the reasons you mentioned above; also, its relative accuracy is guaranteed. Jan 4, 2014 at 16:45
-
I might consider keeping both. If the gaming of the client time is a concern, you could always get the time from an online atomic clock. Jan 5, 2014 at 3:46
-
1You last paragraph is gold. How I could forget about the outbox in e-mail clients? An e-mail message sits in the outbox until it is sent to the mail server and only then is transferred to the "sent messages" folder. Makes it perfectly clear what the sent time should be. Jan 5, 2014 at 11:28
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.
-
Save is not the same as sent. Sent is when the user presses send. The fact that the message is in a queue for hours because of connectivity problems does not alter the fact that the user was finished with the message when (s)he pressed the send button. The shipper will also use the time that they put a collected item on a loading bay (or whatever) as the time they sent it. They won't use the time at which the transport truck arrived and picked it up. Though of course in this scenario you would often get separate times for each part of the process. Jan 4, 2014 at 13:08
-
Reading @cinnamon's answer: how could I forget about the outbox :-) An item on the loading bay is analogous to an e-mail message in your outbox... It still does not mean the "sent moment" should be the time that the server sent it, but the time that the client transmitted it to the mail server (the time the item was loaded onto a truck). Because the message could spent a long time in the server's out queue and the client wouldn't know anything about that. Jan 5, 2014 at 11:25
"sent time" strongly suggests the time sent by the sender, not the time received or processed.
One caveat here is, if the sending software not under your control or hacked it could cheat on the timestamp to unfairly advantage someone.
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.
answered Jan 4, 2014 at 9:11
