Closed relrod closed 9 years ago
Sound Ok. Could we however change the name of the function like utc_format() or formatdatetime() or even just remove the "fix" from the name.
Ok, how about now?
:+1:
Making the datetime objects "aware" by passing them a tzinfo would be more flexible and a bit less hacky. You probably don't need it for the pieces of code I see being modified here but it might help to future proof the code.
Here's an example of creating a simple tzinfo class for UTC: http://stackoverflow.com/questions/19654578/python-utc-datetime-objects-iso-format-dont-include-z-zulu-or-zero-offset
fas2 also required pytz. pytz provides a UTC tzinfo class so if fas3 will still require it you can just use that. From the pytz docs:
It is safe for timezones without daylight saving transitions though, such as UTC: datetime(2002, 10, 27, 12, 0, 0, tzinfo=pytz.utc).strftime(fmt) '2002-10-27 12:00:00 UTC+0000'
See the comment above
fix_utc_iso_format
infas/utils/__init__.py
, but the general idea is that Python's datetime carries no timezone information. So when it's used for UTC, it breaks the specification (which says that it, if noZ
or+HHMM
or-HHMM
is specified, then the time should be treated as local time).Furthermore, since it's invalid, it makes it impossible to correctly parse in environments which are more strict about following the ISO format, since such environments are timezone-aware and won't know which timezone to tag the timestamp with.
Note that this fix is very unideal: Since Python is unityped, there's no way to ensure that the object passed to
fix_utc_iso_format
is really a UTC time. This means that if a local time is passed tofix_utc_iso_format
, we will once again break the ISO spec and render it as a UTC timestamp. (If it's not adatetime
object at all, who knows what runtime error will happen, but this issue is everywhere in Python, not specific tofix_utc_iso_format
.)Signed-off-by: Ricky Elrod ricky@elrod.me