Dear implementors: Codeplex does not seem to be processing my registration, so I will send in my bug report here. Sorry about the problems that will cause. Meanwhile, accept my applause at how well ipy 2.0 is working. I should have the port of adodbapi done in a few more days. Good work!
This bug will cause adodbapi to return false time values from DATETIME and TIME data fields, but the error will only be seen if the application programmer elects to use old python time encoding. The default will be to use datetime encoding and will not be effected, so this can be considered as a minor restriction. The Iron Python implementation of time.mktime and time.gmtime use a value which is two hours (7200 seconds) different from C Python. The C Python value is consistent with datetime.datetime and System.DateTime. The attached script gives the following: v v v v v v v $IPY>script1.py 2.5.2 (r252:60911, Feb 21 2008, 13:11:45) [MSC v.1310 32 bit (Intel)] Starting with tt = (2002, 6, 28, 15, 20, 1, 4, 179, -1) COMDate= 37435.6389005 mktime= 1025299201.0 using time.gmtime= (2002, 6, 28, 15, 20, 1, 4, 179, 0) using datetime = 2002-06-28 15:20:01.004000 $IPY>ipy script1.py $IPY>"C:\Program Files\IronPython 2.0 Beta4\ipy.exe" script1.py 2.5.0 (IronPython 2.0 Beta (2.0.0.4000) on .NET 2.0.50727.1433) Starting with tt = (2002, 6, 28, 15, 20, 1, 4, 179, -1) COMDate= 37435.6389005 mktime= 1025306401.0 using time.gmtime= (2002, 6, 28, 13, 20, 1, 4, 179, 0) using datetime = 2002-06-28 15:20:01.004000 using System = 6/28/2002 3:20:01 PM ^ ^ ^ ^ ^ Note that the ipy result for time.gmtime returns the hour as 13, rather than 15. -- Vernon Cole
_______________________________________________ Users mailing list [email protected] http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
