Hi Peter, On 15 May 2012 22:10, Peter Bigot <big...@acm.org> wrote: > Thanks for the detailed investigation. Before getting into the > contextualized responses below, did you use PyXB 1.1.3 for that, or > were you using the current development version (the next branch from > git)? I'm seeing some differences in behavior locally, and don't know > whether it's because of the large number of changes to PyXB's > date/time classes since the last release, or environment differences.
I was using PyXB 1.1.3. I repeated the tests against the git-next branch this morning using Python 2.7.3 (compiled from source) on SuSE Linux Enterprise 11 SP2 x64. Here's what I get (first block is 1.1.4-DEV; second block is 1.1.3): (pyenv-pyxb-next)nathanr@gionta:~/work/junkcode/pyxb-datetime-test> python test2.py datetime.datetime.now() prints 2012-05-16 09:38:58.946262 Using PyXB 1.1.4-DEV, Python 2.7.3 (default, Apr 30 2012, 14:51:37) [GCC 4.3.4 [gcc-4_3-branch revision 152973]] <?xml version="1.0" ?><ns1:timestamp xmlns:ns1="http://test.com/test";>2012-05-14T16:36:02.157+10:00</ns1:timestamp> --> 2012-05-14 06:36:02.157000+00:00 --> <?xml version="1.0" ?><ns1:timestamp xmlns:ns1="http://test.com/test";>2012-05-14T06:36:02.157Z</ns1:timestamp> <?xml version="1.0" ?><ns1:timestamp xmlns:ns1="http://test.com/test";>2012-05-14T06:36:02.157Z</ns1:timestamp> --> 2012-05-14 06:36:02.157000+00:00 --> <?xml version="1.0" ?><ns1:timestamp xmlns:ns1="http://test.com/test";>2012-05-14T06:36:02.157Z</ns1:timestamp> <?xml version="1.0" ?><ns1:timestamp xmlns:ns1="http://test.com/test";>2012-05-14T16:36:02.157</ns1:timestamp> --> 2012-05-14 16:36:02.157000 --> <?xml version="1.0" ?><ns1:timestamp xmlns:ns1="http://test.com/test";>2012-05-14T16:36:02.157</ns1:timestamp> (pyenv-pyxb-next)nathanr@gionta:~/work/junkcode/pyxb-datetime-test> (pyenv-zktraining)nathanr@gionta:~/work/junkcode/pyxb-datetime-test> python test2.py datetime.datetime.now() prints 2012-05-16 09:45:35.325685 Using PyXB 1.1.3, Python 2.7.3 (default, Apr 30 2012, 14:51:37) [GCC 4.3.4 [gcc-4_3-branch revision 152973]] <?xml version="1.0" ?><ns1:timestamp xmlns:ns1="http://test.com/test";>2012-05-14T16:36:02.157+10:00</ns1:timestamp> --> 2012-05-14 06:36:02.157000 --> <?xml version="1.0" ?><ns1:timestamp xmlns:ns1="http://test.com/test";>2012-05-14T06:36:02.157Z</ns1:timestamp> <?xml version="1.0" ?><ns1:timestamp xmlns:ns1="http://test.com/test";>2012-05-14T06:36:02.157Z</ns1:timestamp> --> 2012-05-14 06:36:02.157000 --> <?xml version="1.0" ?><ns1:timestamp xmlns:ns1="http://test.com/test";>2012-05-14T06:36:02.157Z</ns1:timestamp> <?xml version="1.0" ?><ns1:timestamp xmlns:ns1="http://test.com/test";>2012-05-14T16:36:02.157</ns1:timestamp> --> 2012-05-14 16:36:02.157000 --> <?xml version="1.0" ?><ns1:timestamp xmlns:ns1="http://test.com/test";>2012-05-14T16:36:02.157</ns1:timestamp> (pyenv-zktraining)nathanr@gionta:~/work/junkcode/pyxb-datetime-test> The only difference between the behaviour in 1.1.3 and 1.1.4-DEV is that "+00:00" is printed, and confirms that it is printing GMT for some reason. Is this environmental or something to do with my configuration? The Java version of these tests picks up I'm +10:00, and I also re-ran the tests on 1.1.4-DEV with both the SuSE provided Python 2.6.0 and on Ubuntu 11.10 with their packaged version of Python 2.7.2 and the output is still the same (+00:00). What do you get in your environment? > In particular, it appears to me that datetime.datetime.now() and > xsd.dateTime.now() are essentially the same: > > llc[21]$ cat /tmp/p1.py > import datetime > import pyxb.binding.datatypes as xsd > > def showdt (dt): > print 'class %s\n\ttimezone %s\n\tstr %s' % (type(dt), dt.tzinfo, str(dt)) > > showdt(datetime.datetime.now()) > showdt(xsd.dateTime.now()) > llc[22]$ python /tmp/p1.py > class <type 'datetime.datetime'> > timezone None > str 2012-05-15 06:30:12.653698 > class <class 'pyxb.binding.datatypes.dateTime'> > timezone None > str 2012-05-15 06:30:12.653771 > llc[23]$ Yeah, that test passes ok. I get the same result. > PyXB should always use the canonical representation when converting a > value to text in a context where it will be used in XML, i.e. via > v.xsdLiteral(). It will defer to the underlying Python implementation > when converting a value to text by implicit or explicit use of str(). Section 3.2.7.3 (http://www.w3.org/TR/xmlschema-2/#dateTime) suggests that canonical and non-canonical formats equivalent and interchangeable. It would be a feature to be able to configure which of the formats XML generated by PyXB will produce. It needn't be the same time zone as the input - it makes sense to me to output non-canonical times with respect to the local time zone, not the inputted time zone (if any). >> 2. Python printing out pyxb.binding.datatypes.dateTime's as GMT when >> it prints out datetime.datetime's as local time is inconsistent. It >> should represent itself to code (and print out its value) as local >> time, not GMT. It should be compatible with datetime.datetime, which >> it extends, and hence can be (and does get) used in place of in client >> code. For mine, this is a PyXB bug, and is causing us problems in our >> code at the moment. > > I believe this is fixed. Perhaps the issue I'm seeing is environmental. As I noted above, could you re-run the test I'm running (I'll include the code at the bottom of this post) and confirm whether you're seeing the same behaviour as me? > If you use my test program and add: > > showdt(xsd.dateTime.today().aslocal()) > > you can see behavior more like what you may want: > > class <type 'datetime.datetime'> > timezone <pyxb.utils.utility.LocalTimeZone object at 0x260db50> > str 2012-05-15 02:02:27.455888-05:00 > > Note that you have to use today() because now() produces a > non-timezoned time, and the addition of the timezone screws things up. > I'm not sure why I made PyXB's today() overload explicitly include a > timezone. At the moment, that seems like a mistake, and I should have > used a different name for that, since the documentation for > datetime.today() explicitly says the tzinfo in the result is None. > http://docs.python.org/library/datetime.html#datetime-objects Now that explains a lot, actually. When I add aslocal() in, I get: <?xml version="1.0" ?><ns1:timestamp xmlns:ns1="http://test.com/test";>2012-05-14T16:36:02.157+10:00</ns1:timestamp> --> 2012-05-14 06:36:02.157000+00:00 2012-05-14 16:36:02.157000+10:00 --> <?xml version="1.0" ?><ns1:timestamp xmlns:ns1="http://test.com/test";>2012-05-14T06:36:02.157Z</ns1:timestamp> Which would work, except aslocal() doesn't exist in the base datetime type: >>> print datetime.datetime.now() 2012-05-16 10:35:10.274615 >>> print datetime.datetime.now().aslocal() Traceback (most recent call last): File "<stdin>", line 1, in <module> AttributeError: 'datetime.datetime' object has no attribute 'aslocal' >>> This morning we decided to make a change to our Java code to always output dates with no timezone information, and PyXB puts out datetime.datetime objects without tzinfo set as without timezone information as well. So totally turning off time zones information in both directions is a workaround that we can work with in our particular situation. > One possibility I would entertain is an option to prevent PyXB from > performing the normalize-to-UTC step when processing timezoned times. > In that case, the tzinfo information would be present and not have a > zero offset, and the underlying Python's datetime class should provide > the preserved timezone when being converted via str(). > > I'm not absolutely convinced that this is a great idea, though, since > it's so incredibly easy to screw things up when dealing with > timezones. I would have thought this would have been the right way. If I'm understanding you correctly, this should make pyxb's dateTime object symmetrical and interchangable with the base datetime object, which should be a design goal. Regards, Nathan. Python test code (appologies for GMail's text wrapping of lines below - I don't think it can be turned off): import datetime import pyxb import pyxb_generated import sys """ $ pyxbgen --schema-root=. -u schema.xsd -m pyxb_generated <xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"; targetNamespace="http://test.com/test"; xmlns:zenkai="http://test.com/test";> <xsd:element name="timestamp" type="xsd:dateTime"/> </xsd:schema> """ xml_list = ('<?xml version="1.0" ?><ns1:timestamp xmlns:ns1="http://test.com/test";>2012-05-14T16:36:02.157+10:00</ns1:timestamp>', '<?xml version="1.0" ?><ns1:timestamp xmlns:ns1="http://test.com/test";>2012-05-14T06:36:02.157Z</ns1:timestamp>', '<?xml version="1.0" ?><ns1:timestamp xmlns:ns1="http://test.com/test";>2012-05-14T16:36:02.157</ns1:timestamp>',) print "datetime.datetime.now() prints {0}".format(datetime.datetime.now()) print "Using PyXB {0}, Python {1}".format(pyxb.__version__, sys.version) for xml in xml_list: obj = pyxb_generated.CreateFromDocument(xml) print "{0} --> {1} --> {2}".format(xml, obj, obj.toxml()) ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ pyxb-users mailing list pyxb-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/pyxb-users
