Issue 166 in couchdb-python: DateTimeField and time zone
couchdb...@googlecode.com
Owner: ----
Labels: Type-Defect Priority-Medium
New issue 166 by kxepal: DateTimeField and time zone
http://code.google.com/p/couchdb-python/issues/detail?id=166
What steps will reproduce the problem?
1. Imagine that where is some document where DateTime fields are controls
document modification timestamp.
2. You are in Moscow (GMT+3). Save data in DateTime field. For example, now
there is 12.02.2011 22:16:40 (datetime.now() result). Save document to
couchdb database. Your data would be showed as 2011-02-12T22:16:40Z.
3. You friend in London (GMT+0). Now there is 12.02.2011 19:16:50. He
opening your document and...document have been changed in future!
What is the expected output? What do you see instead?
Two variants:
1. That is not couchdb-python problem to know in what timezone datetime
value have been passed, only UTC+00:00 expected. Ok, but there is no
documentation warnings about it. However, if I'll try to pass datetime
value with explicit timezone information I'll break DateTimeField - see
attachment for small test case. In fact of exception, that was valid ISO
8601 datetime, just not Z one. This only means that converted datetime
value is invalid. And there is no way how only to keep such vital
information.
2. This is couchdb-python problem to convert any non UTC datetime value to
explicitly UTC datetime value and vice versa. I don't think that this
option right and will this make work with couchdb-python more relaxer?
What version of the product are you using? On what operating system?
couchdb-python-0.9@9f1da1f174
pytz 2011b
linux 2.6.36-gentoo-r5
windows 2003
Please provide any additional information below.
Attachments:
timezone.py 459 bytes
couchdb...@googlecode.com
Comment #1 on issue 166 by djc.ocht...@gmail.com: DateTimeField and time
zone
http://code.google.com/p/couchdb-python/issues/detail?id=166
We could go two ways on this one: either (1) dump and load the timezone
data with the datetime (is this unambiguously possible with the datetime
tools included in the stdlib?), or (2) make sure to reject any timezone
data before submitting it to the database. Either would be fine with me, I
suppose, option 1 is a bit more work but also more useful. Second (and
third, etc.) opinions would be welcome here.
couchdb...@googlecode.com
Comment #2 on issue 166 by kxepal: DateTimeField and time zone
http://code.google.com/p/couchdb-python/issues/detail?id=166
I agree with 1) because "Explicit is better than implicit.". Time zone data
could be retrieved via time.altzone(to save DST info) - it's enough to form
valid ISO UTC offset - or from datetime if it had been setted. However,
there is needed some datetime.tzinfo class generator to return datetime
value with needed tzinfo.
couchdb...@googlecode.com
Comment #3 on issue 166 by kxepal: DateTimeField and time zone
http://code.google.com/p/couchdb-python/issues/detail?id=166
So it's done. This patch provides three tzinfo classes: UTC, Local and
Generic. UTC is used for default case and Z suffix. Local is used if
DateTimeField had been initialized with tzinfo='local' argument and
generates local timezone information. Generic one is for parsed datetime
strings.
Also it adds additional argument to DateTimeField as tzinfo to specify what
tzinfo instance should be used if value missed any information about it.
There would a huge problem with already stored datetime data since it had
been defined in UTC format and you probably would expected them in local
time. Strategy is next:
1. Remove Z suffix from any stored datetime values.
2. Initialize all DateTimeField's with additional argument tzinfo='local'.
3. Save again your documents. They would have correct information about UTC
offset.
Attachments:
DateTimeField-tzinfo.patch 8.9 KB
DateTimeField-tzinfo-tests.patch 4.5 KB
couchdb...@googlecode.com
Comment #4 on issue 166 by klemms...@gmail.com: DateTimeField and time zone
http://code.google.com/p/couchdb-python/issues/detail?id=166
Is this going to be merged to trunk anytime soon?
couchdb...@googlecode.com
Comment #5 on issue 166 by kxepal: DateTimeField and time zone
http://code.google.com/p/couchdb-python/issues/detail?id=166
I'm -1 for this feature(: That was nice idea to keep tzinfo data, but my
experience had showed me that things are bad in real. Because:
- you'll have to convert value to your local time or to Z zone to work
correctly with it.
- you'll get incorrect sorting of datetime values with different offset.
- you'll couldn't use datetime values as key for views without converting
them to unified time zone or you'll get broken filters.
- some CouchDB clients couldn't understand such kind of data.
- some tools couldn't work with tz offset data (by design).
So, much more better to store datetime values with UTC timezone always(:
couchdb...@googlecode.com
Comment #6 on issue 166 by kxepal: DateTimeField and time zone
http://code.google.com/p/couchdb-python/issues/detail?id=166
I take my words back: _replicator database leaves no chances to use only
UTC datetime support in couchdb-python due to _replication_state_time
contains local timezone information.
couchdb...@googlecode.com
Comment #7 on issue 166 by djc.ochtman: DateTimeField and time zone
http://code.google.com/p/couchdb-python/issues/detail?id=166
This issue has been migrated to GitHub. Please continue discussion here:
https://github.com/djc/couchdb-python/issues/166
--
You received this message because this project is configured to send all
issue notifications to this address.
You may adjust your notification preferences at:
https://code.google.com/hosting/settings