Revision history [back]

I know that you can tap a message and get the exact timestamp. This is about the default behaviour, and not having to tap a message to get valid information.

For each message in the new message applicaiton there are simplified timestamps, e.g. "1 hour ago", "3 hours ago" etc. However the resolution is lacking/has rounding error when the conversation is within the "hour" interval.

Now, at 15:50, I have two messages showing "1 hour ago", but one has timestamp at 13:58 and the other at 14:22. They are different conversations and I want to know how far apart they were (one is actually very close to 2 hours).

I think that this coarse distribution is OK once you are beyond a certain timespan, say 3-4 hours. Last hour is too close in time to get rid of this resolution.

Another idea is to insert a timestamp between messages, if too far apart in time. Then the actual timestamp for the message is unneeded imo, but each conversation is timestamped instead.

I know that you can tap a message and get the exact timestamp. This is about the default behaviour, and not having to tap a message to get valid information.

For each message in the new message applicaiton there are simplified timestamps, e.g. "1 hour ago", "3 hours ago" etc. However the resolution is lacking/has rounding error when the conversation is within the "hour" interval.

Now, at 15:50, I have two messages showing "1 hour ago", but one has timestamp at 13:58 and the other at 14:22. They are different conversations and I want to know how far apart they were (one is actually very close to 2 hours).

Another example, one message could have "59 minutes ago" and another "1 hour ago", hinting that they are close in time but actually be 1 hour apart (the latter being sent/received 1 hour 59 minutes ago).

I think that this coarse distribution is OK once you are beyond a certain timespan, say 3-4 hours. Last hour is too close in time to get rid of this resolution.

Another idea is to insert a timestamp between messages, if too far apart in time. Then the actual timestamp for the message is unneeded imo, but each conversation is timestamped instead.

I know that you can tap a message and get the exact timestamp. This is about the default behaviour, and not having to tap a message to get valid information.

For each message in the new message applicaiton there are simplified timestamps, e.g. "1 hour ago", "3 hours ago" etc. However the resolution is lacking/has rounding error when the conversation is within the "hour" interval.

Now, at 15:50, I have two messages showing "1 hour ago", but one has timestamp at 13:58 and the other at 14:22. They are different conversations and I want to know how far apart they were (one is actually very close to 2 hours).

Another example, one message could have "59 minutes ago" and another "1 hour ago", hinting that they are close in time but actually be 1 hour apart (the latter being sent/received 1 hour 59 minutes ago).

I think that this coarse distribution is OK once you are beyond a certain timespan, say 3-4 hours. Last hour is too close in time to get rid of this resolution.

I know that you can tap a message and get the exact timestamp. This is about the default behaviour, and not having to tap a message to get valid information.

For each message in the new message applicaiton there are simplified timestamps, e.g. "1 hour ago", "3 hours ago" etc. However the resolution is lacking/has rounding error when the conversation is within the "hour" interval.

Now, at 15:50, I have two messages showing "1 hour ago", but one has timestamp at 13:58 and the other at 14:22. They are different conversations and I want to know how far apart they were (one is actually very close to 2 hours).

Another example, one message could have "59 minutes ago" and another "1 hour ago", hinting that they are close in time but actually be 1 hour apart (the latter being sent/received 1 hour 59 minutes ago).

I think that this coarse distribution is OK once you are beyond a certain timespan, say 3-4 hours. Last hour is too close in time to get rid of this resolution.