On 08/01/2015 02:01 PM, Alexander Belopolsky wrote:
On Sat, Aug 1, 2015 at 4:51 PM, Ethan Furman wrote:
I just also think that part our "gold standard" is refusing the temptation to guess what the result should have been when handed a non-strict dt that is either ambiguous or non-existent.
Ethan, you responded to a joke, but snipped the substantive argument.
My apologies.
I don't have much input about the actual algorithms to use, and, quite frankly, still find DST irritating and confusing. It wasn't until a couple years ago that somebody taught me "fall back, spring forward" so I could at least keep straight which way the clock was going to shift.
So really my involvement here is as a user of these things -- and as a user I would be greatly frustrated with being able to hand an ambiguous/non-existent date/time to a strict dt/tzinfo and not get an error because sooner or later the guess would be wrong and I'd be wondering what happened.
-- ~Ethan~
On Sat, Aug 1, 2015 at 6:35 PM, Ethan Furman ethan@stoneleaf.us wrote:
So really my involvement here is as a user of these things -- and as a user I would be greatly frustrated with being able to hand an ambiguous/non-existent date/time to a strict dt/tzinfo and not get an error because sooner or later the guess would be wrong and I'd be wondering what happened.
Luckily, tzinfo does not currently have a "to_utc()" method, so we can implement it in tzstrict as
def to_utc(self, dt): o0, o1 = self.utcoffset(dt), self.utcoffset(dt.replace(first=not dt.first)) if o0 == o1: return dt + o0 if (o0 < o1) == dt.first: raise AmbiguousLocalTimeError else: raise InvalidLocalTimeError
However, some programers may prefer to get more than one bit of information whenever they query the timezone database. The problem with an InvalidLocalTimeError is that it does not help the user to correct it. Rather than saying "invalid time - try again", it would be more helpful to say something like: "02:30 is invalid, would you like to schedule your event for [ ] 01:30; [ ] 03:30; or other: ____". This will require knowledge that 01:30 and 03:30 are valid, which you will have after you called self.utcoffset(dt) and self.utcoffset(dt.replace(first=not dt.first)), but the hypothetical to_utc() function will discard that knowledge.
-
Alexander Belopolsky -
Ethan Furman