Custom Query (121 matches)
Results (16 - 18 of 121)
|#25||fixed||Constructor and representer for datetimes with timezone do not match||xi||lele@…|
I noticed what seems a little glitch in PyYAML handling of datetime when they carry a timezone.
The regexp used to match the various fields assumes there is a separator between the fractional part and the timezone offset, while the representer simply appends the offset without any separator, effectively resulting in a wrong representation (in the case the offset is positive).
Moreover, unicode(data.utcoffset()) gives something like "-1 day, 22:00" for an offset of -2 hours.
|#26||fixed||yaml.load("a: n") raises exception (problem with bool)||xi||zbynek.winkler@…|
r59 claims to "Remove y/n from the boolean constants." However 'n|N' is not removed from the corresponding regexp. BTW: why was it removed? Looking at http://yaml.org/type/bool.html one would expect it to be there.
|#30||fixed||Timestamp support has floating-point roundoff||xi||edemaine@…|
>>> import yaml, datetime >>> yaml.dump(datetime.datetime(2005, 7, 8, 17, 35, 4, 517600)) '2005-07-08 17:35:04.517600\n' >>> yaml.load(_) datetime.datetime(2005, 7, 8, 17, 35, 4, 517599)
This breaks the desired rule that yaml.load(yaml.dump(x)) == x in a case where there should be no roundoff. (datetime.datetime uses integers everywhere to avoid any error.)
The offending code seems to be line 321 in yaml/constructor.py:
fraction = int(float(values['fraction'])*1000000)
This seems to be an "easy" way to convert the trailing '.517600' into an integer, but it can go beyond floating-point precision. Wouldn't the following work?
fraction = int(values['fraction'][:6].ljust(6, '0'))