
On 27 July 2015 at 22:10, Tim Peters <tim.peters@gmail.com> wrote:
1. Converting to and from them. That's messy because the conversion to UTC needs more information than just the date & time (typically, for example, there is a day when 01:45:00 maps to 2 distinct UTC times). This is basically the "is_dst" bit that Tim discussed in an earlier post. The semantic issue here is that users typically say "01:45" and it never occurs to them to even think about *which* 01:45 they mean. So recovering that extra information is hard (it's like dealing with byte streams where the user didn't provide details of the text encoding used).
"Flatly impossible" is more on target than "hard". In the case of text encoding, it's often possible to guess correctly by statistical analysis of the bytes. 01:45:00 in isolation gives no clue at all about whether standard or daylight time was intended. A similar point applies to some ambiguous cases when the base ("standard") UTC offset changes.
By "hard", what I meant was that you'd have to explain what you need to the user, and accept their answer, in the user interface to your application. Explaining why you need to know in a way that isn't totally confusing is what I classed as "hard". I wouldn't even consider trying to guess the user's intent. Although "if you don't say, I'll use naive datetimes" seems to me a plausible position to take if you want to allow the user not to care. Strange that this is how Python works... ;-) Paul