On Thu, Jan 02, 2003, Guido van Rossum wrote:
Aahz:
I'm confused: are you saying that Guido's calendar doesn't get internally converted to UTC?
That's correct. I use a Palmpilot, which has no knowledge of timezones or DST at all. In fact, I write down appointments in whatever local time I will be in on a specific date, i.e. if I were to fly to California to meet with you at 1pm on some date, I'd put that down for 1pm on that date; on the plane I'll set the Palmpilot's clock back three hours.
I've heard of a calendar application on Windows (Outlook?) that records all your appointments in UTC and displays them in local time. That means that when you are temporarily in a different timezone and you change your computer's clock to match local time, all your appointments are displayed in that local time -- which means that if you want to look up an appointment next week when you're back home, it is shown wrong! (E.g. a 1pm appointment in Washington DC would show up as 10am when the user is in San Francisco -- very confusing when you're in SF talking on the phone to a potential customer on the east coast!)
All that is true and makes perfect sense -- but then Tim's comment about converting your calendar to someone else's wall clock makes no sense.
If not, then the chart from your message starting this thread doesn't apply, because here you're talking about converting from wall clock to wall clock, which I think is a conversion that makes no sense -- that perhaps would be a suitable occasion for an exception.
You can get from wall clock + tzinfo to UTC quite easily using the utcoffset() method of the tzinfo -- that's what it is for. So wall clock to wall clock conversion reduces to UTC to wall clock conversion anyway.
No, because there's no information about *which* wall clock is being used. As you yourself said above, you casually enter times for appointments in the local time that you expect to use them, without recording the extra information needed to make conversions.
If Guido's appointment does get converted to UTC, then there's always a sensible (if possibly ambiguous) conversion to wall time, and if he looks at his calendar, he should be able to see if his appointment got converted to UTC correctly.
No -- why would I care about UTC or even know the UTC offset of my wall clock time? If I make an appointment for early next April, why should I have to know whether DST applies or not at that particular date?
You don't -- but when your application displays wall time, you'd see a discrepency from the time you entered. This only applies when there's a consistent system of timezone information. You can't do date/time arithmetic and conversions with pure wall clock. Period. Python should raise exceptions if you try. -- Aahz (aahz@pythoncraft.com) <*> http://www.pythoncraft.com/ "There are three kinds of lies: Lies, Damn Lies, and Statistics." --Disraeli