On Monday, March 23, 2015 at 7:53:31 AM UTC-7, Jonathan Vanasco wrote: > > > > On Sunday, March 22, 2015 at 7:01:35 PM UTC-4, Bao Niu wrote: >> >> Also because sql datetime datatype doesn't persist timezone information. >> Therefore, I tried to store all the time information as strings. >> > > If your database doesn't support timezones, I think it would be easiest to > convert everything to UTC as a Datetime and then add a second INT column > with the time zone offset. You can create a property method on > SqlAlchemy models to create a new 'timestamp_display' out of both columns. > (you might even be able to write a custom column type) > > That approach will let you do all the in-database sorting you need, and > then use the offset to customize the time for display. If you store as > strings, you'll lose all the benefits of the database's datetime > sorting/searching/miscellaneous functions and have to write custom > compatibility in SQL/SqlAlchemy. that is a lot more work than splitting > the data into 2 columns. >
Hi Jonathan, To make sure that I understand it right, did you mean "hybrid attribute methods" when you mentioned "property methods" here? Thanks -- You received this message because you are subscribed to the Google Groups "sqlalchemy" group. To unsubscribe from this group and stop receiving emails from it, send an email to sqlalchemy+unsubscr...@googlegroups.com. To post to this group, send email to sqlalchemy@googlegroups.com. Visit this group at http://groups.google.com/group/sqlalchemy. For more options, visit https://groups.google.com/d/optout.
