News for hackers. Stuff that matters.

A comment on Date parsing performance on iOS (NSDateformatter vs sqlite). Parent comment

Re:Date parsing performance on iOS (NSDateformatter vs sqlite) by mikeash on Saturday September 07, 2013 @08:14AM (#6344826)
Precision can be fixed by just adding a decimal point. And a "UNIX time stamp" doesn't need a time zone because it's always UTC.

However, you're overall point there remains valid, because people will try to pass off something as a "UNIX time stamp" that is actually in a different time zone. There is value to self-describing data.

[ Parent | on HN ]
Re:Date parsing performance on iOS (NSDateformatter vs sqlite) by hughw on Saturday September 07, 2013 @02:06PM (#6345879)
It's frequently important to preserve the original time zone offset of a timestamp. Sending everything as UTC loses that information.
[ Parent | on HN ]
Re:Date parsing performance on iOS (NSDateformatter vs sqlite) by haberman on Saturday September 07, 2013 @02:48PM (#6346079)
There is nothing preventing you from sending a time zone offset (or an Olson timezone id like 'America/Los_Angeles') along with the Unix Time.
[ Parent | on HN ]
Re:Date parsing performance on iOS (NSDateformatter vs sqlite) by TheZenPsycho on Saturday September 07, 2013 @09:35PM (#6347443)
Sure no problem. We just have to invent a new format.
[ Parent | on HN ]
Re:Date parsing performance on iOS (NSDateformatter vs sqlite) by jessedhillon on Sunday September 08, 2013 @12:54AM (#6347873)
That's what JSON is for:

{timestamp: xyz, tz: "America/Los_Angeles"}

[ Parent | on HN ]