Even more proer tip: only use binary representations of variables until presented to the user.

This is great until someone asks whether a particular event happened before or after lunch.

I always felt the answer to this question is both, since there is always yesterday and tomorrow as far as lunch is concerned, so everything by definition is both before and after lunch. Perhaps the question is ill formed and needs to ask if the time was before, during or after lunch, during the day of the timestamp while defining what during means. That would have a more normal answer.

The question is clear.

You are obfuscating it, for your own entertainment.

It is unclear to me. It has been ever since I was a child. This is what happens with periodicity. There is no 1 lunch reference point when you just say lunch in this sort of question.

You're not alone, believe me, but one of the things you have to learn at some point is that for the vast majority of the population the question is perfectly clear. This is an example of the midwit meme, something like this:

IQ 55: it happened before lunch,

IQ 100: "lunch" isn't a time, lunch for whom? And which lunch? Their first ever lunch? Do babies even have lunch?

IQ 145: it happened before lunch.

Usually, people with higher IQs are the ones who have trouble with such things. There is a logical difference between “before lunch” and “before lunch that day”. This is similar to how higher IQ individuals see the Monty hall problem as having a 2/3 probability rather than a 1/2 probability in the famous version of the problem posed to Marilyn vos Savant. They are often derided as being idiots for not having “common sense”, even when their remarks are correct.

That said, IQ is considered obsolete given the theory of multiple intelligences. IQ only covers a subset of it.

There's no reliable way to map it back into the local time in the past, unless you also safe the UTC offset.

If you record them with some known UTC offset regardless of localtime (e.g. 0), you can convert to local time in the past.

The problem with that is you lose the localtime information, which you may want. Say you have recorded the localtime with the known UTC offset of 0, and that localtime is midnight UTC. Now you want to map it back to a localtime in the past. Ok, which localtime? Was it 8pm in NYC? Or was it 5pm in LA? Is the assumption that the localtime is wherever the user is right now, and is that a valid assumption? If the user has traveled to a different timezone, the time is now being converted to a localtime in the past that is different than it actually was when it happened.

edit: another commenter shared this link with an example: https://codeblog.jonskeet.uk/2019/03/27/storing-utc-is-not-a...

I like their "Principle of preserving supplied data".

> If the user has traveled to a different timezone, the time is now being converted to a localtime in the past that is different than it actually was when it happened.

I consider this to be a desirable behavior.

For most cases I think that would be correct, but I will say if I am looking at my ATM withdrawals for a trip I made to San Francisco, I would like the time shown to be the SF time and not that of my local hometown, and vice versa if I'm in SF.