> Properly storing timezone-aware times
I'd just like to point out that a lot of RDBMSs support storing date and time alongside timezone information directly without using two separate fields. SQL Server has datetimeoffset, PostgreSQL has timestamp with time zone, and Oracle has timestamp with time zone. I think MySQL does as well, but I seem to recall something strange about it. Or maybe that's just me expecting MySQL to do something weird.
Similarly, most programming languages have support for datetimes with time zones.
It's still all a huge pain in the butt, but you don't need to use two fields and ensure that you use both all the time. Also, you can meaningfully compare datetimes within the same database without translating the timezone if its all in one field.
Also, of course, remember that a even a time with timezone without a date attached to it is inherently ambiguous.
I'd just like to point out that a lot of RDBMSs support storing date and time alongside timezone information directly without using two separate fields. SQL Server has datetimeoffset, PostgreSQL has timestamp with time zone, and Oracle has timestamp with time zone. I think MySQL does as well, but I seem to recall something strange about it. Or maybe that's just me expecting MySQL to do something weird.
Similarly, most programming languages have support for datetimes with time zones.
It's still all a huge pain in the butt, but you don't need to use two fields and ensure that you use both all the time. Also, you can meaningfully compare datetimes within the same database without translating the timezone if its all in one field.
Also, of course, remember that a even a time with timezone without a date attached to it is inherently ambiguous.