Adding a UnixDateTimeField to Models

[Jean Stebens]

Hi there,

Beside the normal DateTime fields in databases, there are often legacy systems working with unix timestamps as DateTime. Having a UnixDateTimeField helps setting the Unix Timestamps over the comfortable Calender and Date choosing helper in the Django Admin. This is a preview what a UnixDateTimeField might look like:

### Definition:

class UnixDateTimeField(models.DateTimeField):

    __metaclass__ = models.SubfieldBase

    def get_internal_type(self):
        return 'PositiveIntegerField'

    def to_python(self, value):
        if value is None or isinstance(value, datetime):
            return value
        if isinstance(value, date):
            return datetime(value.year, value.month, value.day)
        return datetime.fromtimestamp( float(value) )

    def get_db_prep_value(self, value):
        return int( time.mktime( value.timetuple() ) )

    def value_to_string(self, obj):
        value = self._get_val_from_obj(obj)
        return self.to_python(value).strftime('%Y-%m-%d %H:%M:%S')


### Usage:
class Downtime(models.Model):
    id = models.AutoField(primary_key=True, db_column='id') 
    service = models.ForeignKey(Service, db_column='id') 
    begin = UnixDateTimeField(db_column='begin')

[James Bennett]

This really doesn't feel like something that needs to be in core, and it's easy enough to write and package up your own field for distribution.

[Jean Stebens]

Probably the same reason why USStateField shouldnt be in core, hm? Actually the UnixTimestampField has even a better reason to be in there as for the USStateField, given that lots of legacy databases and mysql perform faster on these fields than DateTime crap.

[Chris Beaven]

You're speaking to a brick wall here, nemesys. Bring it up in the django-dev google group if you're really passionate about it.