On 01/20/2010 11:46 PM, Jerome Leclanche wrote: > > I've worked on a DurationField implementation (ticket: > http://code.djangoproject.com/ticket/2443). However I was extremely > displeased with the whole DecimalField backend. > With the recent addition of BigIntegerField, I am now saving durations > with a bigint and mapping them to timedelta. I wanted to post an > updated patch with that overhaul but never got around to do it; since > you seem to need it I'll do that right now. > It's the same DurationField I use on > http://db.mmo-champion.com/items/?duration=3600000000 - it can store > up to a few hundred thousand years in microseconds, ought to be enough > for everybody, right? :)
That sounds interesting, but I tend to prefer using the SQL TIME type. It doesn't feature such precision, but it's more consistent and readable when browsing the database directly: it's a time column and it contains time information. Things get quite obscure with big integers IMO. If you want to go that way, then why wouldn't the TimeField itself be stored as a numeric type, for microseconds precision too? But it's not, and I think there's a good reason for it: AFAICS Django fields try to follow quite closely SQL types, and I think that it's a good thing. It make things transparent. And if someone needs high precision then he/she can use a numeric field explicitly. The problem I see with the current TimeField is that it's not *consistent* with the SQL TIME type, at least on MySQL and SQLite, and that could be called a bug, actually. -- Olivier
-- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
