41–50 of 118 posts
> A time format without an offset is useless. 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.
This won't work for any system that allows users to schedule events in the future. Let's say that you agree for a meeting in Moscow 1 dec 2013 3pm. The actual (astronomical) time of meeting might change significantly if they change daylight saving rules. So you need to store something like "2013-12-01 15:00 Moscow", there's no way around it.
> A time format without an offset is useless. 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.
This topic comes up again and again. But I mostly read only about the problems, not about the solutions. This post advises to use Unix timestamps. That's already what I'm doing mostly everywhere. And it seems to me like most people do and like this is somewhat accepted as the best available option - but still not perfect. Then I am wondering again: Isn't there really a perfect solution? Esp., the problems with Unix t…
> A time format without an offset is useless. 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.
But this will still be useless anywhere else than "locally". The timezone just became implicit and lost.
This topic comes up again and again. But I mostly read only about the problems, not about the solutions. This post advises to use Unix timestamps. That's already what I'm doing mostly everywhere. And it seems to me like most people do and like this is somewhat accepted as the best available option - but still not perfect. Then I am wondering again: Isn't there really a perfect solution? Esp., the problems with Unix t…
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' (typically the Unix epoch but anything else will do too). Yeah. Hmm. Clearly an opinion expressed without either reading, comprehension, or experience. Why would I say that? Well, consider your statement about "actual seconds elapsed since epoch". Leaving aside the fact that Unix Time enumerates…
I don't doubt that you have valuable experience and information to lend to the discussion, but your frame seems aggressively negative towards the OP with no discernible reason.
Advice to display an offset when displaying a time is wrong or at least incomplete; you should display a symbolic timezone (i.e. "London" or "Eastern US" etc.) as that's what's going to be meaningful to someone reading it.
> 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.