from Hacker News

Python Enhancement Proposal 495: Local Time Disambiguation

by philipn on 8/21/15, 1:05 AM with 35 comments

• by kbenson on 8/21/15, 7:24 AM

  I'm not sure the rationale behind this. That is, the rationale section of the proposal does a poor just of explaining any case where this is actually a problem.

  In every case where I've seen this problem, it's a matter of people either not storing the timezone along with the local time, or not storing in UTC time. A local time with a timezone is a unique time, it does not occur twice. A UTC time additionally does not occur twice. Store a time zone along with the date and time or store in UTC and convert on use.

  Note: If there are instances where a second is repeated, it's rare special occurrence that developing a formalized interface for seems like overkill.

• by toyg on 8/21/15, 8:57 AM

  Terrible PEP, I hope it gets rejected. One-off flags like this are hacks that shouldn't be in stdlib. It simply stinks, in an area (time handling) where the stdlib does not really smell like roses already.

  Dealing with time adjustments is the OS's job, not userland. If your job has to be scheduled exactly and cannot rely on the OS, and you refuse to deal with UTC, it's your own damn fault and you can always just use a long-running process with timers.

• by lifeisstillgood on 8/21/15, 7:26 AM

  So :

  Time in UK is currently UTC +1 (BST) At 2am on 25 OCT we will return to GMT / UTC. It will therefore become 1am, and for the next hour all times will have happened before

  The idea is to put a bit flag that says "alreadyseenthistime"

  It seems to me this is a solution to the wrong problem.

  Store all strings as bytes, assuming UTF-8, store all times as longs assuming UTC

  If we convert all python datelines to non-naive (ie embedded with a TZ) then we are forced always to choose an encoding just like in strings. The right encoding is to always assume incoming dates are UTC, to throw error if they are non naive, and to assume that local clocks are set correctly (which we do anyway)

  I need to read it more carefully - but it seems the wrong solution

• by Marazan on 8/21/15, 10:01 AM

  In general any solution to datetimes that doesn't involve the time being in UTC is solving thew wrong problem.

• by IanCal on 8/21/15, 6:00 AM

  When the clocks change, don't you shift timezone? There aren't duplicate times in BST, we just switch from GMT to BST and then back.

  > In these situations, the information displayed on a local clock (or stored in a Python datetime instance) is insufficient to identify a particular moment in time.

  Does the datetime instance not store the timezone?

• by mayoff on 8/21/15, 11:39 PM

  The more I'm exposed to other date/time libraries, the more impressed I become with Apple's date/time library.

  https://developer.apple.com/library/mac/documentation/Cocoa/...