What date format to use when dealing with android and django?

Question

ISO 8601? For example django is good with this format:

ValidationError at /locations/new_tracks/1351320785
["'1351320785' value has an invalid format. It must be in YYYY-MM-DD  HH:MM[:ss[.uuuuuu]][TZ] format."]

Or unixtime? It is important for me to have a timezone. Asking because I don't have experience dealing with server-client systems written in two different frameworks.

I don't understand why you present `ValidationError` as the evidence of: *"django is good with this format"*. (it indicates the opposite that the code does not understand the format) — jfs, Jan 23 '16 at 21:09
I fed him unixtime and he refused by saying It must be in YYYY-MM-DD HH:MM[:ss[.uuuuuu]][TZ] format."] which is 8601 — nutella_eater, Jan 24 '16 at 08:22

score 1 · Accepted Answer · edited May 23 '17 at 11:48

1

Django almost always internally stores dates in UTC time using a database field of appropriate date/time type for the underlying database. You cannot access this directly - when reading/writing the database it will be converted to/from a Python "datetime" object, described in detail in the Python docs. Converting between Unix time (specifically POSIX time which is specified in terms of UTC) and Python datetimes in UTC time is straightforward using datetime.datetime.utcfromtimestamp and time.mktime(t.timetuple()). Converting between Python datetimes and ISO 8601 can be done with the iso8601 package.

If you need to support local time zone date/times, even if it's just one local time zone, you should enable time zone support as detailed in the Django time zones documentation. This will add complexity, but as the documentation notes, "This shields you from subtle and unreproducible bugs around Daylight Saving Time (DST) transitions."

edited May 23 '17 at 11:48

Community

1
1

answered Jan 23 '16 at 07:15

D Coetzee

789
5
5

Unix time is not in UTC. It is not in any timezone. Though, you can convert "seconds since the Epoch" to UTC time on POSIX easily (`utc_time = datetime(1970, 1, 1) + timedelta(seconds=timestamp)`). – jfs Jan 23 '16 at 20:59
POSIX.1-2008 [specifies](http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap04.html#tag_04_15) that epoch time is in terms of UTC, not counting leap seconds - that's what I was referring to by Unix time here, although some systems may use slightly different semantics. – D Coetzee Jan 25 '16 at 19:57
do you understand the difference between "is always UTC" and "convert .. easily"? The fact that you can't represent some valid UTC time as "epoch time" unambiguously hints that "is" is not appropriate here. See [Does Python's time.time() return the local or UTC timestamp?](http://stackoverflow.com/a/20035913/4279) – jfs Jan 25 '16 at 20:06
Sorry, I misunderstood you - I thought you meant that Unix time was a naive timestamp (with its interpretation determined by context rather than standardized). Of course Unix time is not literally UTC, just specified in terms of UTC. I edited the answer slightly to clarify. – D Coetzee Jan 25 '16 at 23:17
If "right" timezone is used then Unix time is NOT specified in terms of UTC (it uses TAI time scale in this case (1970-01-01 00:00:10 TAI epoch and you can convert to/from any *past* UTC time unambiguously (the relation for *future* (+6m) timestamps is unknown)). You can [use `utcfromtimestamp()`, to get UTC time from the timestamp](http://stackoverflow.com/a/33426779/4279)). In general (C standard), *"The `time()` function returns the implementation’s best approximation to the current calendar time."* (i.e., it is not limited to UTC, TAI or any other time scale, timezone) – jfs Jan 26 '16 at 09:35
If you define "Unix time" as the time returned by the time() function, you are correct. I was definining it as POSIX time as specified in POSIX.1-2008. This is just a matter of semantics. – D Coetzee Jan 26 '16 at 18:32
I don't see the word POSIX in your answer. – jfs Jan 26 '16 at 18:56
Edited to clarify that I was referring to POSIX time. – D Coetzee Jan 26 '16 at 19:28
So, which format should I use in both my applications? – nutella_eater Jan 26 '16 at 19:35
It's app-dependent. If you're doing everything in a single process in Python, just use datetime objects as your representation. If you need to exchange between your Python app and another app via a serialized form, see the recommendations in this answer (top answers recommend using string formats like ISO 8601 and RfC 3339): http://stackoverflow.com/questions/455580/json-datetime-between-python-and-javascript – D Coetzee Jan 26 '16 at 19:50

score 0 · Answer 2 · edited Oct 07 '21 at 13:31

The error message says explicitly what format should you use:

It must be in YYYY-MM-DD HH:MM[:ss[.uuuuuu]][TZ] format.

If all you have is a Unix time then convert it to UTC time (represented by a datetime object) and serialize it using RFC 3339 time format (a profile of ISO 8601):

>>> from datetime import datetime
>>> datetime.utcfromtimestamp(1351320785).isoformat() + 'Z'
'2012-10-27T06:53:05Z'

If your android client doesn't understand rfc 3339, try variations:

>>> datetime.utcfromtimestamp(1351320785).isoformat(' ') + '+00:00'
'2012-10-27 06:53:05+00:00'
>>> datetime.utcfromtimestamp(1351320785).isoformat(' ') + '+0000'
'2012-10-27 06:53:05+0000'

.strftime() method provides even more flexibility.

What date format to use when dealing with android and django?

2 Answers2