> 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 in the last few years? Maybe asking for a conversion for a > date in 2004 invokes some old rules which then affect a conversion for > a date in 2005, even though that would be really bad behaviour (which > I don't see on this machine here).
According to this page: http://www.timeanddate.com/worldclock/timezone.html?n=238 In 2004 daylight change was done on October 31, while in 2005 it was done on October 30. Maybe this fact cause the difference in "guess what is the current daylight offset" behavior ?? > Well, it really isn't overlapping as such: you're in different zones, > of course. ;-) Heh, got it ... apparently "Europe/Sofia" is not a single timezone, it is an alias for two timezones :) > I think it's easiest to install one of the libraries which provides > the zone data. The first one that comes to mind is python-dateutil, > but I think there are others. Thanks I will try it. Once again, thanks for your helpfull responses ! Ivan On Jun 9, 12:11 pm, Paul Boddie <[EMAIL PROTECTED]> wrote: > 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: > > > +------------+---------------------+---------------------+ > > | gmt_stamp | gmt_time | local_time | > > +------------+---------------------+---------------------+ > > | 1130631000 | 2005-10-30 00:10:00 | 2005-10-30 03:10:00 | > > +------------+---------------------+---------------------+ > > | 1130634600 | 2005-10-30 01:10:00 | 2005-10-30 03:10:00 | > > +------------+---------------------+---------------------+ > > | 1130638200 | 2005-10-30 02:10:00 | 2005-10-30 04:10:00 | > > +------------+---------------------+---------------------+ > > | 1130641800 | 2005-10-30 03:10:00 | 2005-10-30 05:10:00 | > > +------------+---------------------+---------------------+ > > 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 in the last few years? Maybe asking for a conversion for a > date in 2004 invokes some old rules which then affect a conversion for > a date in 2005, even though that would be really bad behaviour (which > I don't see on this machine here). > > > When you do local-time-to-GMT conversion you can expect any of those > > two timestamps. I missed that initially :( (I was sure that local time > > has "one hour gap" and not "one hour of overlapping time") > > Well, it really isn't overlapping as such: you're in different zones, > of course. ;-) > > > > and I'd recommend the datetime module for any serious work with dates > > > and times. > > > Last time when I was playing with TZ conversions, I was not able to do > > anything using datetime module - it seems that one needs to define his > > own set of timezones (+ all the details) to get it working ... Am I > > wrong ? Can you show me how do accomplish the same conversion using > > datetime module ? > > I think it's easiest to install one of the libraries which provides > the zone data. The first one that comes to mind is python-dateutil, > but I think there are others. > > Paul -- http://mail.python.org/mailman/listinfo/python-list
