Re: [Tutor] datetime, time zones, and ISO time
On Wed, Feb 17, 2010 at 12:44:02PM -0600, David Perlman wrote: I have been really scratching my head over this, it seems like there *should* be a nice easy way to do what I want but I can't find it for the life of me. ... But a) I don't know how to stick the offset info into a datetime object, and the documentation doesn't seem to say anything about this; and b) the offset line doesn't work anyway: I think that you need to push in a tzinfo object, rather than a value: http://docs.python.org/library/datetime.html#datetime.tzinfo I get that from here: For applications requiring more, datetime and time objects have an optional time zone information member, tzinfo, that can contain an instance of a subclass of the abstract tzinfo class. These tzinfo objects capture information about the offset from UTC time, the time zone name, and whether Daylight Saving Time is in effect. Note that no concrete tzinfo classes are supplied by the datetime module. Supporting timezones at whatever level of detail is required is up to the application. The rules for time adjustment across the world are more political than rational, and there is no standard suitable for every application.[1] I suspect that it'll take some fooling around to see how it works though - use the interpreter or ipython to test things out. [1] http://docs.python.org/library/datetime.html -- yours, William ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] datetime, time zones, and ISO time
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! On Feb 17, 2010, at 1:42 PM, William Witteman wrote: On Wed, Feb 17, 2010 at 12:44:02PM -0600, David Perlman wrote: I have been really scratching my head over this, it seems like there *should* be a nice easy way to do what I want but I can't find it for the life of me. ... But a) I don't know how to stick the offset info into a datetime object, and the documentation doesn't seem to say anything about this; and b) the offset line doesn't work anyway: I think that you need to push in a tzinfo object, rather than a value: http://docs.python.org/library/datetime.html#datetime.tzinfo I get that from here: For applications requiring more, datetime and time objects have an optional time zone information member, tzinfo, that can contain an instance of a subclass of the abstract tzinfo class. These tzinfo objects capture information about the offset from UTC time, the time zone name, and whether Daylight Saving Time is in effect. Note that no concrete tzinfo classes are supplied by the datetime module. Supporting timezones at whatever level of detail is required is up to the application. The rules for time adjustment across the world are more political than rational, and there is no standard suitable for every application.[1] I suspect that it'll take some fooling around to see how it works though - use the interpreter or ipython to test things out. [1] http://docs.python.org/library/datetime.html -- yours, William ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: http://mail.python.org/mailman/listinfo/tutor -- -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 ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] datetime, time zones, and ISO time
On Wed, Feb 17, 2010 at 3:12 PM, David Perlman dperl...@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 ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] datetime, time zones, and ISO time
On Wed, Feb 17, 2010 at 3:48 PM, David Perlman dperl...@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, 87) 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 dperl...@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 ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] datetime, time zones, and ISO time
But this doesn't help, because then you still don't know whether it's dst or not. You then would have to jump through whatever convolutions to do that calculation. All I want to know is the *current* offset between local time and utc. I know the system has this information already; it doesn't require any kind of fancy calculations about global politics or anything. On Feb 17, 2010, at 3:12 PM, Kent Johnson wrote: On Wed, Feb 17, 2010 at 3:48 PM, David Perlman dperl...@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. -- -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 ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] datetime, time zones, and ISO time
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 dperl...@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, 87) 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 dperl...@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 ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] datetime, time zones, and ISO time
On Wed, Feb 17, 2010 at 03:24:26PM -0600, David Perlman wrote: But this doesn't help, because then you still don't know whether it's dst or not. You then would have to jump through whatever convolutions to do that calculation. All I want to know is the *current* offset between local time and utc. I know the system has this information already; it doesn't require any kind of fancy calculations about global politics or anything. Well, does time.timezone help? It returns time offset from UTC in seconds. -- yours, William ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] datetime, time zones, and ISO time
On Wed, Feb 17, 2010 at 4:37 PM, David Perlman dperl...@wisc.edu wrote: 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?? Here is a shorter version based on the LocalTimezone example, and it only gets the time once so there is no possible race condition: In [5]: from datetime import timedelta In [6]: import time In [15]: def utcoffset(): : if time.localtime().tm_isdst 0: : return timedelta(seconds = -time.altzone) : return timedelta(seconds = -time.timezone) : In [16]: utcoffset() Out[16]: datetime.timedelta(-1, 68400) Kent ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] datetime, time zones, and ISO time
On 17 February 2010 22:37, David Perlman dperl...@wisc.edu wrote: 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?? There is pytz [1] which should provide a simpler way to manage timezone info in python. Greets Sander [1] http://pytz.sourceforge.net/ ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] datetime, time zones, and ISO time
On Feb 17, 2010, at 4:17 PM, Sander Sweers wrote: On 17 February 2010 22:37, David Perlman dperl...@wisc.edu wrote: 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?? There is pytz [1] which should provide a simpler way to manage timezone info in python. Well, this is actually more complicated, not simpler. The description says: pytz brings the Olson tz database into Python. This library allows accurate and cross platform timezone calculations using Python 2.3 or higher. It also solves the issue of ambiguous times at the end of daylight savings, which you can read more about in the Python Library Reference (datetime.tzinfo). I don't want to deal with any of that stuff, I just want to know the actual current offset between local time and UTC. I don't care what the offset is in Nepal; I don't care what the offset will be come summertime; I don't care about anything in the Olson tz database. I just want something to tell me the current offset, right here, right now, on my own computer. Anyway, I already wrote a function to calculate it, so it's a done deal. At this point I'm just really surprised that I had to... For completeness, here's what I came up with. The format function was necessary because Google calendar queries require the time zone to be represented in the string like: 2010-03-01T21:00:00.000-06:00 However the isoformat() methods in python instead give something like: 2010-03-01T21:00:00.000-0600 which gives a server error if you try to send it to Google. Unfortunately, and also bizarrely, even the strftime() doesn't provide any way to generate the format Google demands, so I had to also write a function to do the formatting. def tzDeltaForm(self, tzd=None): return the tzdelta in the format Google wants it, such as -06:00 if not tzd: tzd=self.tzDelta() if tzd 0: sign = -1 tzd = -tzd else: sign = 1 h = sign * tzd // 3600 m = (tzd % 3600) // 60 form = '%+03d:%02d' % (h,m) return form def tzDelta(self): 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) return osec OK, I hope that is helpful to someone else someday, because it has been an astonishing amount of pain to accomplish something seemingly so simple... Thanks to everyone for the input, every bit of it helped guide me along. :) -- -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 ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: http://mail.python.org/mailman/listinfo/tutor
