Also because you shouldn't be passing dates as strings to the database
-
-
Replying to @sgrif
Yup. And for other uses you probably really want ISO 8601.
1 reply 0 retweets 0 likes -
Replying to @joelquen
Nah clearly julian days since 2000-01-01 as a float is the way to go
1 reply 0 retweets 0 likes -
OSX actually uses this format to store time... A lot
1 reply 0 retweets 0 likes -
-
-
Creating your own epoch is pretty common. PG stores time as a 64 bit integer representing microseconds since 01-01-2000 (also I was mistaken in my other tweet, OSX is since 2001)
2 replies 0 retweets 0 likes -
Replying to @sgrif
If you're creating your own time format, epoch + counter is the most sane way to do it. Much nicer than trying to do some kind of human-readable thing.
1 reply 0 retweets 0 likes -
I worked on a project once that represented time-of-day as a 4-digit number. 0000 was null and 2400 was midnight. It allowed all sorts of invalid values like 1075 or 3000. Doing any kind of math, even just generating a human-formatted string was really painful
1 reply 0 retweets 0 likes -
Replying to @joelquen
The problem with epoch + counter is that it can become inaccurate for dates in the future. If I were designing something that had to store time, I'd personally structure it as (i64 for days, i64 for nanos) -- or (i32 for days, i32 for micros) if space was that big of a concern
1 reply 0 retweets 0 likes
"days" and "subsecond thingy" being offsets from an epoch of course. You need days to be separate in order to represent dates in the future accurately though
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.