Cool that is what I thought,
On Feb 19, 2011, at 17:32 , Michael Bayer wrote:
>
>
> On Feb 19, 2011, at 6:40 AM, Martijn Moeling wrote:
>
>> Hi,
>>
>> I would like to store all time values in my database as UTC values
>> (automatically). I already have the proper conversion routines in my own
>> CALDAV server but I have many more places where I would like to store dates.
>>
>> what would be a logical place to hook in those conversion routines so that
>> DateTime and Time values are stored as UTC in the database automatically.
>> The front end code will display the local time as it will consider all
>> values from the database as UTC.
>
> The application itself should coerce all dates into UTC as soon as possible.
> Its best to assume that "local time" is a moving target only decided at the
> very endpoints of the UX, i.e. rendering, data handling. In my experience
> this means the date conversions tend to occur in Python. Any date logic or
> arithmetic that occurs in Python can proceed normally without any timezone
> mismatch. An alternative approach is to use timezone-aware datetimes, but
> the effect is similar, as you still need to coerce incoming data into
> timezone aware constructs.
>
> So I've got a web application, in my templates I display dates like:
>
> ${someobject.created_at | n, formatters.format_datetime_local}
>
> where the function is:
>
> def format_datetime_local(k, format="%Y-%m-%d %H:%M:%S %Z", tz=None):
> if k is None:
> return ""
> if tz is None:
> tz = c.tz
> k = pytz.utc.localize(k)
> k = k.astimezone(tz)
> return k.strftime(format)
>
> When I receive user input, I'm using a formencode validator that handles it.
>
> If the scenario is that there's literally no space between your "front end"
> and your database routines (which is usually unlikely), TypeDecorator is the
> standard construct for data coercion at the point of database interaction -
> still an in-python routine.
>
>
>
>
>
>>
>> Martijn
>>
>>
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "sqlalchemy" group.
>> To post to this group, send email to [email protected].
>> To unsubscribe from this group, send email to
>> [email protected].
>> For more options, visit this group at
>> http://groups.google.com/group/sqlalchemy?hl=en.
>>
>
> --
> You received this message because you are subscribed to the Google Groups
> "sqlalchemy" group.
> To post to this group, send email to [email protected].
> To unsubscribe from this group, send email to
> [email protected].
> For more options, visit this group at
> http://groups.google.com/group/sqlalchemy?hl=en.
>
--
You received this message because you are subscribed to the Google Groups
"sqlalchemy" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/sqlalchemy?hl=en.
