But 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?
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?
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.
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.