[Tutor] datetime, time zones, and ISO time

[David Perlman]

OK, here's a function that does precisely what I want:

def tzDelta():
   """by whatever means necessary, return the current offset of the  
local time from utc."""
   s=time.time()
   t,u=time.localtime(s),time.gmtime(s)
   osec=3600*(t[3]-u[3]) + 60*(t[4]-u[4]) + (t[5]-u[5])
   return datetime.timedelta(seconds=osec)


As far as I can tell, this should always work.  So wouldn't it be nice  
if there were a less convoluted way to get this??


On Feb 17, 2010, at 3:12 PM, Kent Johnson wrote:

> On Wed, Feb 17, 2010 at 3:48 PM, David Perlman <dperlman at wisc.edu>  
> wrote:
>> Surely there is a way to simply print out the local time, date and  
>> time zone
>> without needing to write your own class...  I can't believe this is  
>> the only
>> way...
>>
>> Here's why I don't believe it.  Both the datetime and time modules  
>> provide
>> both functions for returning the current local time, and the  
>> current utc
>> time.  So, assuming that those functions are trustworthy, it *must*  
>> be true
>> that the OS always knows the current offset from utc time.  So why  
>> is there
>> no straightforward way to get that offset in python?  I mean, I can  
>> do this:
>
> time.timezone gives the offset for standard time.
>
> Kent
>
>>
>>>>> datetime.datetime.now()-datetime.datetime.utcnow()
>> datetime.timedelta(-1, 64799, 999987)
>>
>> But then, of course, it's off by a few fractions of a microsecond.   
>> This
>> works:
>>
>>>>> time.localtime()[3]-time.gmtime()[3]
>> -6
>>
>> But doesn't that seem like a ridiculous hack, well outside of the  
>> spirit of
>> the zen of python?  Shouldn't there be one obvious right way to do  
>> this?
>>
>> Yes, I know that as William sent, the documentation points out that  
>> the
>> rules the world over are complicated and irrational.  Nonetheless,  
>> it is
>> implicit in the existing definitions that the system *knows* the  
>> current
>> offset, even if it doesn't know the whole set of rules...
>>
>>
>> On Feb 17, 2010, at 2:26 PM, Kent Johnson wrote:
>>
>>> On Wed, Feb 17, 2010 at 3:12 PM, David Perlman <dperlman at wisc.edu>  
>>> wrote:
>>>>
>>>> Yeah, I got this part.  The thing that's hanging me up is that  
>>>> there
>>>> doesn't
>>>> seem to be any way to get a tzinfo instance that contains the  
>>>> current
>>>> local
>>>> time zone information.  You can do time.timezone to get the  
>>>> seconds from
>>>> UTC, but there doesn't seem to be any way to convert that into a  
>>>> tzinfo!
>>>>  I
>>>> would be perfectly satisfied with this:
>>>>
>>>> tz=offset_to_tzinfo(time.timezone) # or whatever
>>>> aware_now=datetime.datetime.now(tz)
>>>> print aware_now.isoformat()
>>>>
>>>> I'm pretty sure that would give me what I want, but there doesn't  
>>>> seem to
>>>> be
>>>> any way to do step one without subclassing tzinfo.  This makes me  
>>>> feel
>>>> like
>>>> I MUST be missing something obvious, because it shouldn't require  
>>>> so much
>>>> coding just to find out what the current local time and timezone  
>>>> is!
>>>
>>> The docs make it clear that you do have to subclass tzinfo, that no
>>> implementations are provided.
>>> It sounds like you want the LocalTimezone class in the examples at  
>>> the
>>> bottom of this section - "A class capturing the platform's idea of
>>> local time":
>>> http://docs.python.org/library/datetime.html#tzinfo-objects
>>>
>>> Kent
>>
>> --
>> -dave----------------------------------------------------------------
>> "Pseudo-colored pictures of a person's brain lighting up are
>> undoubtedly more persuasive than a pattern of squiggles produced by a
>> polygraph.  That could be a big problem if the goal is to get to the
>> truth."  -Dr. Steven Hyman, Harvard
>>
>>
>>
>>

--
-dave----------------------------------------------------------------
"Pseudo-colored pictures of a person's brain lighting up are
undoubtedly more persuasive than a pattern of squiggles produced by a
polygraph.  That could be a big problem if the goal is to get to the
truth."  -Dr. Steven Hyman, Harvard