> I've tried this with Python 2.3 and 2.4 on Red Hat Enterprise Linux 4 > and can't reproduce the problem, even with other TZ values such as
Thanks for the quick reply. Can you please let me know what value do you receive during your tests ? As far as I can see, Python timezone API is just a wrapper around (shared ) native C libraries, but I really do not have any idea on how to reproduce this issue in a non-Python environment :( btw. problem exists for this particular datetime only, an hour or more before / after that time givse identical results (this particular datetime is near the "daylight saving time change" moment) On Jun 3, 6:01 pm, Paul Boddie <[EMAIL PROTECTED]> wrote: > On 3 Jun, 16:12, Ivan Velev <[EMAIL PROTECTED]> wrote: > > > > > Minimal example below - it gives me different output if I comment / > > uncomment the extra time.mktime call - note that this call is not > > related in any way to main logic flow. > > > When "problematicStamp = ..." is commented I get > > gmtStamp: 1130634600.0 > > > when I uncomment that line I get > > gmtStamp: 1130631000.0 > > I've tried this with Python 2.3 and 2.4 on Red Hat Enterprise Linux 4 > and can't reproduce the problem, even with other TZ values such as > "EEST3" (which appears to be a legal name and does change the > timestamp produced). I don't think much has changed in the time module > since 2.4, which means that there might be some kind of library or > configuration issue involved which causes the observed behaviour. > > Paul -- http://mail.python.org/mailman/listinfo/python-list
