Keeping microsecond precision when passing datetime between django and javascript -

it seems django, or sqlite database, storing datetimes microsecond precision. when passing time javascript date object supports milliseconds:

var stringfromdjango = "2015-08-01 01:24:58.520124+10:00"; var time = new date(stringfromdjango); $('#time_field').val(time.toisostring()); //"2015-07-31t15:24:58.520z" 

note 58.520124 58.520.

this becomes issue when, example, want create queryset objects datetime less or equal time of existing object (i.e. mymodel.objects.filter(time__lte=javascript_datetime)). truncating microseconds object no longer appears in list time not equal.

how can work around this? there datetime javascript object supports microsecond accuracy? can truncate times in database milliseconds (i'm pretty using auto_now_add everywhere) or ask query performed reduced accuracy?

how can work around this?

tl;dr: store less precision, either by:

• coaxing db platform store miliseconds , discard additional precision (difficult on sqlite, think)
• only ever inserting values precision want (difficult ensure you've covered cases)

is there datetime javascript object supports microsecond accuracy?

if encode dates strings or numbers can add accuracy you'd like. there other options (some discussed in thread). unless want accuracy though, it's not best approach.

can truncate times in database milliseconds..

yes, because you're on sqlite it's bit weird. sqlite doesn't have dates; you're storing values in either text, real or integer field. these underlying storage classes dictate precision , range of values can store. there's decent write of differences here.

you could, example, change underlying storage class integer. truncate dates stored in field precision of 1 second. when performing queries js, likewise truncate dates using date.prototype.setmilliseconds() function. eg..

mymodel.objects.filter(time__lte = javascript_datetime.setmilliseconds(0)) 

a more feature complete db platform handle better. example in postgresql can specify precision stored more exactly. add timestamp column precision down miliseconds (matching of javascript)..

alter table "my_table" add "my_timestamp" timestamp (3) time zone 

mysql let same thing.

.. or ask query performed reduced accuracy?

yeah wrong approach.

if criteria you're filtering by precise you're ok; can truncate value filter (like in ..setmilliseconds() example above). if values in db you're checking against precise you're going have bad time.

you could write query such stored values formatted or truncated reduce precision before being compared criteria operation going need performed for every value stored. millions of values. what's more, because you're generating values dynamically, you've circumvented indexes created against stored values.