> I still don't understand why the "problematic" timestamp would affect
> the latter operation, though. I can see that both timestamps could be
> valid depending on which time zone is supposed to be in operation -
> have the dates for daylight saving (summer vs. winter) time changed in
> Bulgaria i
On 9 Jun, 07:40, Ivan Velev <[EMAIL PROTECTED]> wrote:
> Thanks Paul,
>
> I have identified the "problem" - because of daylight change this
> particular timesamp was observed twice in Europe/Sofia. Here is the
> GMT-to-local-time conversion:
>
> ++-+-
Thanks Paul,
I have identified the "problem" - because of daylight change this
particular timesamp was observed twice in Europe/Sofia. Here is the
GMT-to-local-time conversion:
++-+-+
| gmt_stamp | gmt_time| local_time |
+
On 3 Jun, 19:44, Ivan Velev <[EMAIL PROTECTED]> wrote:
> > 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 you
> 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 wr
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
Hello,
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:
