31–40 of 118 posts
Who was the genius who decided that unix time should handle leap seconds? It seems like such an obviously bad idea. The biggest advantage of unix time has always been that it is monotonically increasing and that it is precisely defined as seconds since the epoch, period. And then all of that is now broken because of this decision. Also, does the problem that the leap second solves actually warrant all of the problems…
Sigh. 50 year old numerical / geophysical / real time data acquisition/processing/interpretation programmer here. Unix Time isn't much chop for "real time" continuous data from the "real world" - it's those pesky leap seconds. If you bother to read the first paragraph of the wikipedia article on Unix Time you'll see : > Unix time, or POSIX time, is a system for describing instances in time, defined as the number of s…
Time is tricky but there is a simple fact: it exists such a thing as the number of actual seconds elapsed since 'time x' (typically the Unix epoch but anything else will do too). No leap seconds issues. No 25 hours-day issues. No 23 hours-day issues. No 59 seconds minutes issues. No 61 seconds minutes issues. And all it takes to store a time like that is a 64-bit integer and it is very convenient. And a lot of softwa…
Obviously you don't need to go trough all that trouble if you simply want to display the date you published a post on your blog.
Earlier quoted context omitted.
Time is tricky but there is a simple fact: it exists such a thing as the number of actual seconds elapsed since 'time x' (typically the Unix epoch but anything else will do too). No leap seconds issues. No 25 hours-day issues. No 23 hours-day issues. No 59 seconds minutes issues. No 61 seconds minutes issues. And all it takes to store a time like that is a 64-bit integer and it is very convenient. And a lot of softwa…
> Time is tricky but there is a simple fact: it exists such a thing as the number of actual seconds elapsed since 'time x' Yes and no: it might just exist theoretically, but we have no way to get at it. The closest we have is TAI, which is only an approximation of the time elapsed at mean sea level on the earthly geoid, because clocks fall victim to gravitational time dilatation and compression. To accurately measure…
> When storing time, store Unix time. It's a single number. Don't do this in your database. Use your datetime types. Please. You might save some work with your timezone but you're not going to be able to use intervals etc in a smart way. This would be even dumber with PostgreSQL, which has much more robust date/time functionality (being able to use the - operator with datetimes and intervals, for example) and complet…
Postgresql and every other database that I'm aware of stores dates internally as a 4 or 8 bit number anyway, so you aren't saving anything by using an (hopefully) bigint instead of a datetime column.
Sigh. 50 year old numerical / geophysical / real time data acquisition/processing/interpretation programmer here. Unix Time isn't much chop for "real time" continuous data from the "real world" - it's those pesky leap seconds. If you bother to read the first paragraph of the wikipedia article on Unix Time you'll see : > Unix time, or POSIX time, is a system for describing instances in time, defined as the number of s…
> When storing time, store Unix time. It's a single number. Don't do this in your database. Use your datetime types. Please. You might save some work with your timezone but you're not going to be able to use intervals etc in a smart way. This would be even dumber with PostgreSQL, which has much more robust date/time functionality (being able to use the - operator with datetimes and intervals, for example) and complet…
Sometimes I think Mysql has corrupted everyone's brain. Postgresql and every other database that I'm aware of stores dates internally as a 4 or 8 bit number anyway, so you aren't saving anything by using an (hopefully) bigint instead of a datetime column.
Unsurprising, given how cavalier MySQL is with all the other data it "stores".
1. Google Plus conversation remains https://plus.google.com/106413090159067280619/posts/Wtkhk9jU... Good luck finding it on Twitter
When information is to be transmitted between timezones, you want to be able to determine the locale time of the sender or the information relays. This is why you'll find a time zone information in dates and time stamps in mail headers.
This is also why ISO 8601 bothered to standardize specification of the time zone.
Not necessarily. The time might be "floating time", i.e., depends on some local context.
For example, the show starts at 10 pm 19 Jan 2012. You don't need the time zone because people going to the show know what 10 pm means locally.
I disagree that Timezone is just a presentation issue. When information is to be transmitted between timezones, you want to be able to determine the locale time of the sender or the information relays. This is why you'll find a time zone information in dates and time stamps in mail headers. This is also why ISO 8601 bothered to standardize specification of the time zone.