the Gravity of Python 2

[Piet van Oostrum]

Chris Angelico <rosuav at gmail.com> writes:

> On Fri, Jan 10, 2014 at 1:06 AM, Piet van Oostrum <piet at vanoostrum.org> wrote:
>> Chris Angelico <rosuav at gmail.com> writes:
>>
>>> On Thu, Jan 9, 2014 at 2:34 PM, Ben Finney <ben+python at benfinney.id.au> wrote:
>>>> With time zones, as with text encodings, there is a single technically
>>>> elegant solution (for text: Unicode; for time zones: twelve simple,
>>>> static zones that never change)
>>>
>>> Twelve or twenty-four? Or are you thinking we should all be an even
>>> number of hours away from UTC, which would also work?
>>
>> Even 24 doesn't take into account DST.
>
> That was the point. We can abolish codepages by using Unicode, which
> covers everything. We could abolish time messes by having every
> locality settle permanently on one timezone; Ben's theory demands that
> all timezones be some integer number of hours +/- UTC, which IMO is
> optional, but mainly it should be easy to figure out any two
> locations' difference: just subtract one's UTC offset from the
> other's. Similarly, you can calculate the difference between two times
> at the same location by simple subtraction; currently, you also have
> to consider the possibility of a DST switch (from noon to noon across
> a switch is either 23 or 25 hours).
>
> Actually, the nearest parallel to Unicode is probably "use UTC
> everywhere", which makes for a superb internal representation and
> transmission format, but bugs most human beings :)

I don't know how other countries do it, but here, when the clock goes back, it goes from 03:00 to 02:00. So I wonder how they communicate when your plane leaves at 02:30 in that night. Which 02:30? In that case using UTC may come out handy, if it would be understood. Or do the planes just stop leaving during that interval? Not that there will be many leaving during that time in general, I presume.

-- 
Piet van Oostrum <piet at vanoostrum.org>
WWW: http://pietvanoostrum.com/
PGP key: [8DAE142BE17999C4]