Hacker News new | past | comments | ask | show | jobs | submit login

The 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.




I 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.


I have the exact same confusion as you.




Consider applying for YC's Spring batch! Applications are open till Feb 11.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: