4 ms·
> In other words, the function responsible for transforming a timestamp into a human-readable date is not injective, as each element of the set of timestamps co
by wging 2y ago
> In other words, the function responsible for transforming a timestamp into a human-readable date is not injective, as each element of the set of timestamps corresponds to more than one element of the "human dates" set.
The author confuses the concept of injectivity and well-definedness. For an injective function f, it has to be true that given distinct a and b, f(a) != f(b). That's not the problem here; rather the problem is that for a timestamp t there's no unique human-readable date x such that f(t) = x. That's well-definedness, not injectivity.
https://en.wikipedia.org/wiki/Well-defined_expression https://en.wikipedia.org/wiki/Well-defined_expression
You could talk about the inverse function, from human-readable dates to timestamps, and correctly point out that that function is not injective, because more than one human-readable date maps to the same timestamp...
- jdthedisciple 2y agoBut how does either problem apply to timestamps? if t is 17943000... whatever which translates to say 03:50 AM on Mar 16, 2020 in Greenwich (i.e. UTC+00.00) then it can be converted to any other human readable zoned time. Where is the issue?
- wging 2y agoThe ability to convert it to any human-readable time is actually the problem: without additional information you don't know which one to pick, and are forced to make certain assumptions, such as using the user's local time zone or defaulting to UTC. That's the point of the section of the article I quoted above. For example, given just a timestamp, you don't even know what day it was. Was the user in New York? That 3:50am was actually 11:50pm on March 15th.
- jdthedisciple 2y agoI genuinely still don't get it, but why do you need to fix the reference point once and for all? I would assume in 99% of cases the user is simply just interested in his local time anyway. If you really need the location info, then you would obv have to make some other tradeoffs like either 1) always store the location alongside the timestamp or 2) complicate (probably massively so) the time format, storing and parsing/processing logic But I don't see how that's an issue of UTC timestamps per se rather than being an issue of requiring more information than just time (i.e. time AND location at the time). Again, really would appreciate an explanation of where I am mistaken here because thus far the whole point of OP seems like a trivial non-issue to me.
- xnhbx 2y agoI have the exact same confusion as you.