Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Proper datetime module implementation #326

Open
pyjsorg opened this issue Apr 27, 2012 · 10 comments
Open

Proper datetime module implementation #326

pyjsorg opened this issue Apr 27, 2012 · 10 comments
Labels

Comments

@pyjsorg
Copy link
Contributor

pyjsorg commented Apr 27, 2012

Hello,

I noticed the existing datetime module in pyjs only contains a non-standard
"Datetime" class, which acts as a thin layer above the JS Date class.
In order to comply with the Python standard library, I rewrote the module
to a proper implementation, including datetime.date, datetime.time,
datetime.datetime and datetime.timedelta classes.

Attached is the diff to the old datetime.py source, and an additional unit
test for LibTest to properly test the new implementation.

The patch removes the old "Datetime" class; it was only used once in the
Gears example, and this was easily replaceable. Hope this doesn't break
anybody's code! ;)

Original issue: http://code.google.com/p/pyjamas/issues/detail?id=393 (April 09, 2010 10:48:07)

@pyjsorg
Copy link
Contributor Author

pyjsorg commented Apr 27, 2012

From luke.lei...@gmail.com on April 25, 2010 12:21:07:
excellent! thank you!

@pyjsorg
Copy link
Contributor Author

pyjsorg commented Apr 27, 2012

From luke.lei...@gmail.com on April 25, 2010 12:22:00:
ideally we also need a patch to changelog, CREDITS and copyright.

@pyjsorg
Copy link
Contributor Author

pyjsorg commented Apr 27, 2012

From luke.lei...@gmail.com on April 25, 2010 12:25:26:
no adding extra stuff in patches! slapped wrist! :)

diff --git a/examples/libtest/StringTest.py b/examples/libtest/StringTest.py
index 8e30965..c1d4e69 100644
--- a/examples/libtest/StringTest.py
+++ b/examples/libtest/StringTest.py
@@ -190,6 +190,9 @@ class StringTest(UnitTest):
def testCenter(self):
self.assertEqual('a'.center(4, '1'), '1a11')

  • def testZfill(self):
  •    self.assertEqual('a'.zfill(4), '000a')
    
    def testSprintfList(self):
    self.assertEqual("%s" % 'foo', "foo")
    self.assertEqual("%% %s" % '', "% ")

@pyjsorg
Copy link
Contributor Author

pyjsorg commented Apr 27, 2012

From luke.lei...@gmail.com on April 25, 2010 12:27:02:
DatetimeModuleTest Test failed (testTimestamp) : '2010-04-09 10:16:49.950000'
!= '2010-04-09 11:16:49.950000'
DatetimeModuleTest: Passed 38 / 39 tests (1 failed)

whoops :) that's under standard python2.5 - probably because i haven't got GMT
correctly set.

@pyjsorg
Copy link
Contributor Author

pyjsorg commented Apr 27, 2012

From a.mottola@gmail.com on April 25, 2010 13:34:11:
Thanks for applying.

I'm attaching a diff providing correct copyright informations (thanks for putting my
name up there, but the surname was wrong - my fault for not providing it first time
though!)

I was aware of one test failing in the unit test: it seems I forgot to mention it,
but the cause seems not to be associated with my datetime module, but with the
time.localtime() implementation... The datetime failing test is the one which tests
datetime.timetuple(); this however is a thin wrapper over time.localtime(), so it
seems it is this last one which reports a bad tm.tm_yday value... Not sure which is
the cause though as the localtime() code seems correct to me! Could you have a look
too? Four eyes are always better than two.

@pyjsorg
Copy link
Contributor Author

pyjsorg commented Apr 27, 2012

From cornelis...@gmail.com on May 20, 2010 09:16:00:
I fixed some stuff in the time module (timezone/gmtime/localtime/mktime related). The
failing test disappeared. See r2438

I added a separate script to test the time module at different timezones (with pyv8).
The DatetimeModuleTest can also be run by itself in different timezones (gives some
errors in certain zones, due to hard coded checks for probably CET)

I can't guarantee I've got all the bugs (should run the tests at different clock
times too), but some progress is made.

To run the test in different time zones:

  • runzonetest.sh python TimeModule
  • runzonetest.sh python DatetimeModuleTest
  • runzonetest.sh v8 TimeModule
  • runzonetest.sh v8 DatetimeModuleTest

@pyjsorg
Copy link
Contributor Author

pyjsorg commented Apr 27, 2012

From cornelis...@gmail.com on May 20, 2010 09:23:06:
BTW. I just applied the copyright.diff too

@pyjsorg
Copy link
Contributor Author

pyjsorg commented Apr 27, 2012

From cornelis...@gmail.com on May 20, 2010 09:40:24:
There was only one test in DatetimeModuleTest (testTimestamp) that required CET
timezone. Changed that to a timezone independent check.

See r2440

@pyjsorg
Copy link
Contributor Author

pyjsorg commented Apr 27, 2012

From cornelis...@gmail.com on May 20, 2010 11:52:51:
The "runzonetest.sh v8 DatetimeModuleTest" showed an error in some timezones for
date.fromordinal() and date.toordinal(). Fixed this in r2441.

The datetime.fromordinal() and datetime.toordinal() also need to be fixed. Could you
do that Angelo? (And add some unittest for the datetime class?)

@duly
Copy link
Contributor

duly commented Mar 16, 2014

Have all the patches been added to the master branch as of today?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants