Date parsing performance on iOS (NSDateformatter vs sqlite)

Re:Date parsing performance on iOS (NSDateformatter vs sqlite) by gngeal on Saturday September 07, 2013 @08:49AM (#6344926)

"They complicate referring to a physical instant, because you can refer to it in several timezones, rather than the unique representation of a unix timestamp."

I thought it's supposed to be an external format. I'd always expect a computer system presenting the output information to the user in his local time zone, while accepting inputs from all time zones equally.

"But they're inadequate for political time, because what time comes 6 months after 13:00 (+00:00)? (It could be 13:00 (+01:00) or 13:00 (+00:00) or likely others - you need a symbolic timezone like "Europe/Lisbon")."

You can't standardize a changing practice. I'd never expect it to deal with these issues.

[ Parent | on HN ]

Re:Date parsing performance on iOS (NSDateformatter vs sqlite) by lmm on Saturday September 07, 2013 @12:08PM (#6345420)

>I thought it's supposed to be an external format. I'd always expect a computer system presenting the output information to the user in his local time zone, while accepting inputs from all time zones equally.

We're talking about a web API here, not user display. But even so, IME users don't think of their timezones as "+8" or the like, so for human I/O you want to use symbolic timezone names, not offsets.

[ Parent | on HN ]