On 13/02/20 9:17 AM, Michael Torrie wrote:
On 2/12/20 7:44 AM, Ethan Furman wrote:
On 02/11/2020 04:38 PM, Michael Torrie wrote:
...
True. Costs can be calculated and planned for. But Technical debt is
often impossible to quantify in a real, meaningful, business sense,
other than the that we
On 2/12/20 7:44 AM, Ethan Furman wrote:
> On 02/11/2020 04:38 PM, Michael Torrie wrote:
>
>> It's all just different ways of accounting for the same things. In
>> the olden days before the term "technical debt" was invented, we
>> called this "total cost of ownership."
>
> TCO is not a fixed numb
On 12/02/2020 17:46, Python wrote:
On Wed, Feb 12, 2020 at 01:16:03PM +, Rhodri James wrote:
On 12/02/2020 00:53, Python wrote:
In pretty much every job I've ever worked at, funding work (e.g. with
humans to do it) with exactly and precisely the resources required is
basically impossible, a
On Wed, Feb 12, 2020 at 01:16:03PM +, Rhodri James wrote:
> On 12/02/2020 00:53, Python wrote:
> > In pretty much every job I've ever worked at, funding work (e.g. with
> > humans to do it) with exactly and precisely the resources required is
> > basically impossible, and management prefers to
t: Re: Technical debt - was Re: datetime seems to be broken WRT
timezones (even when you add them)
On 12/02/2020 00:53, Python wrote:
> In pretty much every job I've ever worked at, funding work (e.g. with
> humans to do it) with exactly and precisely the resources required is
> basica
On 02/11/2020 04:38 PM, Michael Torrie wrote:
It's all just different ways of accounting for the same things. In the
olden days before the term "technical debt" was invented, we called this
"total cost of ownership."
TCO is not a fixed number. For example, if a loan is taken to help fund a pr
On 12/02/2020 00:53, Python wrote:
In pretty much every job I've ever worked at, funding work (e.g. with
humans to do it) with exactly and precisely the resources required is
basically impossible, and management prefers to underfund the work
than to overfund it, for cost-savings reasons. This ba
On 2020-02-12, Chris Angelico wrote:
> But you CAN rewrite code such that it reduces technical debt. You can
> refactor code to make it more logical.
... but if doing so costs more than the debt, you shouldn't do it.
--
https://mail.python.org/mailman/listinfo/python-list
On Wed, Feb 12, 2020 at 12:32 PM Michael Torrie wrote:
>
> On 2/11/20 6:15 PM, Chris Angelico wrote:
> > On Wed, Feb 12, 2020 at 12:13 PM Michael Torrie wrote:
> >>
> >> On 2/11/20 5:55 PM, Chris Angelico wrote:
> >>> But you CAN rewrite code such that it reduces technical debt. You can
> >>> ref
On 2/11/20 6:15 PM, Chris Angelico wrote:
> On Wed, Feb 12, 2020 at 12:13 PM Michael Torrie wrote:
>>
>> On 2/11/20 5:55 PM, Chris Angelico wrote:
>>> But you CAN rewrite code such that it reduces technical debt. You can
>>> refactor code to make it more logical. You can update things to use
>>> i
On 2/11/20 5:53 PM, Python wrote:
> If your hypothetical project was implemented perfectly from the
> beginning, in Python2.x, it may never need updating, and therefore
> there may well never be any reason to port it to python3. So doing so
> would be neither "debt" nor "cost" but rather "waste."
On Wed, Feb 12, 2020 at 12:13 PM Michael Torrie wrote:
>
> On 2/11/20 5:55 PM, Chris Angelico wrote:
> > But you CAN rewrite code such that it reduces technical debt. You can
> > refactor code to make it more logical. You can update things to use
> > idioms that better express the concepts you're
On 2/11/20 5:55 PM, Chris Angelico wrote:
> But you CAN rewrite code such that it reduces technical debt. You can
> refactor code to make it more logical. You can update things to use
> idioms that better express the concepts you're trying to represent
> (maybe because those idioms require syntacti
On Wed, Feb 12, 2020 at 12:00 PM Michael Torrie wrote:
>
> On 2/11/20 5:42 PM, Chris Angelico wrote:
> > Yes, if you consider the term to be synonymous with TCO, then
> > naturally you'll see it as useless. But it isn't. Technical debt is a
> > very specific thing and it CAN be paid off.
>
> We'll
On 2/11/2020 3:09 PM, Chris Angelico wrote:
What you're talking about is costs in general, but "debt" is a very
specific term. You accrue technical debt whenever you "borrow" time
from the future - doing something that's less effort now at the
expense of being worse in the future.
A prime examp
On Wed, Feb 12, 2020 at 11:48 AM Michael Torrie wrote:
>
> On 2/11/20 5:37 PM, Chris Angelico wrote:
> > On Wed, Feb 12, 2020 at 11:32 AM Michael Torrie wrote:
> >>
> >> On 2/11/20 2:25 PM, Barry Scott wrote:
> >>> At Chris said moving to python3 will *reduce* your technical debt.
> >>> You are p
On 2/11/20 5:42 PM, Chris Angelico wrote:
> Yes, if you consider the term to be synonymous with TCO, then
> naturally you'll see it as useless. But it isn't. Technical debt is a
> very specific thing and it CAN be paid off.
We'll agree to disagree on the last bit. And I'm not the only one that
bel
On Wed, Feb 12, 2020 at 07:09:12AM +1100, Chris Angelico wrote:
> On Wed, Feb 12, 2020 at 7:03 AM Michael Torrie wrote:
> > Speaking about technical debt is certainly fashionable these days. As
> > if we've somehow discovered a brand new way of looking at things. But
> > it doesn't matter what y
On 2/11/20 5:37 PM, Chris Angelico wrote:
> On Wed, Feb 12, 2020 at 11:32 AM Michael Torrie wrote:
>>
>> On 2/11/20 2:25 PM, Barry Scott wrote:
>>> At Chris said moving to python3 will *reduce* your technical debt.
>>> You are paying off the debt.
>>
>> While at the same time incurring new debt.
>
On Wed, Feb 12, 2020 at 11:39 AM Michael Torrie wrote:
>
> On 2/11/20 1:09 PM, Chris Angelico wrote:
> > What you're talking about is costs in general, but "debt" is a very
> > specific term. You accrue technical debt whenever you "borrow" time
> > from the future - doing something that's less eff
On 2/11/20 1:09 PM, Chris Angelico wrote:
> What you're talking about is costs in general, but "debt" is a very
> specific term. You accrue technical debt whenever you "borrow" time
> from the future - doing something that's less effort now at the
> expense of being worse in the future. You pay off
On Wed, Feb 12, 2020 at 11:32 AM Michael Torrie wrote:
>
> On 2/11/20 2:25 PM, Barry Scott wrote:
> > At Chris said moving to python3 will *reduce* your technical debt.
> > You are paying off the debt.
>
> While at the same time incurring new debt.
That's not an intrinsic part of the rewrite, and
On 2/11/20 2:25 PM, Barry Scott wrote:
> At Chris said moving to python3 will *reduce* your technical debt.
> You are paying off the debt.
While at the same time incurring new debt.
> Not to mention that its harder to hire people to work on tech-debt legacy
> code.
>
> Given the choice between
> On 11 Feb 2020, at 20:01, Michael Torrie wrote:
>
> On 2/11/20 4:05 AM, Chris Angelico wrote:
>> Or just the recognition that, eventually, technical debt has to be
>> paid.
>
> Speaking about technical debt is certainly fashionable these days. As
> if we've somehow discovered a brand new
> On 10 Feb 2020, at 23:01, Python wrote:
>
> As best I can tell, Python has no means to make use of the system's
> timezone info. In order to make datetime "timezone aware", you need
> to manually create a subclass of datetime.tzinfo, whose methods return
> the correct values for the timezone
On Wed, Feb 12, 2020 at 7:03 AM Michael Torrie wrote:
>
> On 2/11/20 4:05 AM, Chris Angelico wrote:
> > Or just the recognition that, eventually, technical debt has to be
> > paid.
>
> Speaking about technical debt is certainly fashionable these days. As
> if we've somehow discovered a brand new
On Wed, Feb 12, 2020 at 6:45 AM Python wrote:
>
> On Wed, Feb 12, 2020 at 05:38:38AM +1100, Chris Angelico wrote:
> > > > Isn't it time to stop going to great effort to support Python
> > >
> > > If you live in a world where you get to decide that, sure. Not
> > > everyone does.
> > >
> >
> > Eve
On 2/11/20 4:05 AM, Chris Angelico wrote:
> Or just the recognition that, eventually, technical debt has to be
> paid.
Speaking about technical debt is certainly fashionable these days. As
if we've somehow discovered a brand new way of looking at things. But
it doesn't matter what you do, there
On Wed, Feb 12, 2020 at 05:38:38AM +1100, Chris Angelico wrote:
> > > Isn't it time to stop going to great effort to support Python
> >
> > If you live in a world where you get to decide that, sure. Not
> > everyone does.
> >
>
> Everyone gets to decide how much time and effort they put into
> su
On Wed, Feb 12, 2020 at 3:57 AM Python wrote:
>
> On Tue, Feb 11, 2020 at 12:42:26PM +1100, Chris Angelico wrote:
> > > > I've been using the timestamp() method:
> > >
> > > That's the key piece of info. This does appear to work, though still
> > > not on python2. That, as you say, is my problem
On Tue, Feb 11, 2020 at 12:42:26PM +1100, Chris Angelico wrote:
> > > I've been using the timestamp() method:
> >
> > That's the key piece of info. This does appear to work, though still
> > not on python2. That, as you say, is my problem. But thankfully Jon
> > Ribbens has the save:
>
> Isn't
On 2020-02-11, Chris Angelico wrote:
> On Tue, Feb 11, 2020 at 10:01 PM Jon Ribbens via Python-list
> wrote:
>> So while it's been about 6 years since anyone should have been
>> starting any new projects using Python 2, there are plenty of
>> projects that are older than that and still need suppor
On Tue, Feb 11, 2020 at 10:01 PM Jon Ribbens via Python-list
wrote:
>
> On 2020-02-11, Chris Angelico wrote:
> >> That's the key piece of info. This does appear to work, though still
> >> not on python2. That, as you say, is my problem. But thankfully Jon
> >> Ribbens has the save:
> >
> > Isn
On 2020-02-11, Chris Angelico wrote:
>> That's the key piece of info. This does appear to work, though still
>> not on python2. That, as you say, is my problem. But thankfully Jon
>> Ribbens has the save:
>
> Isn't it time to stop going to great effort to support Python 2?
That depends on what
On Tue, Feb 11, 2020 at 12:31 PM Python wrote:
>
> On Tue, Feb 11, 2020 at 11:33:54AM +1100, Chris Angelico wrote:
> > [...] instead of using the undocumented and unsupported strftime %s
> > format code
>
> I'm not sure this characterization is accurate... the docs (for both
> Python 2 and 3) say:
On Tue, Feb 11, 2020 at 11:33:54AM +1100, Chris Angelico wrote:
> [...] instead of using the undocumented and unsupported strftime %s
> format code
I'm not sure this characterization is accurate... the docs (for both
Python 2 and 3) say:
The full set of format codes supported varies across pl
On 2020-02-10, Python wrote:
> So far, so good. However, when you go to use this object, the time it
> represents is in fact wrong.
Unsurprisingly for a language feature that's been around for nearly
17 years, no it isn't.
> For example:
>
print dt.strftime("%s")
> 1580452245
That's askin
On Tue, Feb 11, 2020 at 11:17 AM Python wrote:
>
> On Tue, Feb 11, 2020 at 11:04:28AM +1100, Chris Angelico wrote:
> > On Tue, Feb 11, 2020 at 10:42 AM Python wrote:
> > > Now, you can instantiate a datetime.datetime object with the times you
> > > want, and pass an instance of this class as the
On Tue, Feb 11, 2020 at 11:04:28AM +1100, Chris Angelico wrote:
> On Tue, Feb 11, 2020 at 10:42 AM Python wrote:
> > Now, you can instantiate a datetime.datetime object with the times you
> > want, and pass an instance of this class as the tzinfo argument to the
> > constructor. Also no problem:
On Tue, Feb 11, 2020 at 10:42 AM Python wrote:
>
> As best I can tell, Python has no means to make use of the system's
> timezone info. In order to make datetime "timezone aware", you need
> to manually create a subclass of datetime.tzinfo, whose methods return
> the correct values for the timezo
nfo, whose methods return
> > the correct values for the timezone you care about.
> >
> ...
>
> > Does Python have an alternative way to do the above, with correct
> > results?
> >
>
> The datetime module's manipulation of timezones is pretty low-level. M
t;
...
> Does Python have an alternative way to do the above, with correct
> results?
>
The datetime module's manipulation of timezones is pretty low-level. Maybe
try arrow?
https://arrow.readthedocs.io/en/latest/
Skip
>
--
https://mail.python.org/mailman/listinfo/python-list
As best I can tell, Python has no means to make use of the system's
timezone info. In order to make datetime "timezone aware", you need
to manually create a subclass of datetime.tzinfo, whose methods return
the correct values for the timezone you care about. In the general
case, this is hard, but
e not gonna be able to do much better for you as far as "why"
> goes.
>
> http://pytz.sourceforge.net/
>
> "Unfortunately using the tzinfo argument of the standard datetime
> constructors "does not work" with pytz for many timezones."
>
>
I'd say if the documentation mentions it, but doesn't say why, then we're not
gonna be able to do much better for you as far as "why" goes.
http://pytz.sourceforge.net/
"Unfortunately using the tzinfo argument of the standard datetime constructors
"does not
I made a small script to practise with timezones:
#!/usr/bin/env python3
# -*- coding: utf_8 -*-
from datetime import datetime, timedelta
from pytz import timezone
import pytz
amsterdam_datetime = datetime(2018, 12, 17, 11, 31, 26,
tzinfo=timezone('Europe/Amsterdam'))
print(amsterda
s for that location. For most locations,
that is something called "LMT" or Local Mean Time, which is the
customary time in use at that location prior to the standardization of
timezones. And in most locations, LMT is offset from UTC by a strange
number of minutes. That's why you see &q
On Saturday, June 11, 2016 at 11:37:38 PM UTC+12, Johannes Bauer wrote:
> I try to create a localized timestamp in the easiest possible way.
Localized timestamps are perhaps not as easy as you think.
> So, intuitively, I did this:
>
> datetime.datetime(2016,1,1,0,0,0,tzinfo=pytz.timezone("Europe
Hi there,
first off, let me admit that I have a hard time comprehensively wrapping
my head around timezones. Everything around them is much more
complicated than it seems, IMO. That said, I'm trying to do things the
"right" way and stumbled upon some weird issue which I can't
On 11-6-2016 13:37, Johannes Bauer wrote:
> Hi there,
>
> first off, let me admit that I have a hard time comprehensively wrapping
> my head around timezones. Everything around them is much more
> complicated than it seems, IMO.
They might not seem complicated, but ac
.datetime(2016, 3, 14, 9, 30, tzinfo= 'America/New_York' EDT-1 day, 20:00:00 DST>)
>>>> ot.tzinfo
>
I've stubbed my toe many times on timezones and DST. Here are
some notes I've accumulated:
* datetime.datetime(..., tzinfo=tz) doesn't work right for t
Hi Skip,
On 03/14/2016 09:32 AM, Skip Montanaro wrote:
> On Mon, Mar 14, 2016 at 10:26 AM, Ian Kelly wrote:
>> Why should it? You only asked pytz for the Chicago timezone. You
>> didn't ask for it relative to any specific time.
>
> Thanks. I thought using America/Chicago was supposed to automagi
documentation, you should.
> http://pythonhosted.org/pytz/
Thanks. I have remained pretty naive about timezones (sorry for the
pun). The platform I use actually does the right thing, but like a
dope I failed to use the mechanisms it provided.
Skip
--
https://mail.python.org/mailman/listinfo/python-list
On Mon, Mar 14, 2016 at 9:32 AM, Skip Montanaro
wrote:
> On Mon, Mar 14, 2016 at 10:26 AM, Ian Kelly wrote:
>> Why should it? You only asked pytz for the Chicago timezone. You
>> didn't ask for it relative to any specific time.
>
> Thanks. I thought using America/Chicago was supposed to automagic
On Mon, Mar 14, 2016 at 10:26 AM, Ian Kelly wrote:
> Why should it? You only asked pytz for the Chicago timezone. You
> didn't ask for it relative to any specific time.
Thanks. I thought using America/Chicago was supposed to automagically
take into account transitions into and out of Daylight Sav
On Mon, Mar 14, 2016 at 9:19 AM, Skip Montanaro
wrote:
> Is this correct (today, with Daylight Savings in effect)?
>
import pytz
i.timezone
> 'America/Chicago'
pytz.timezone(i.timezone)
>
ot
> datetime.datetime(2016, 3, 14, 9, 30, tzinfo= 'America/New_York' EDT-1 day, 20:00:00
Is this correct (today, with Daylight Savings in effect)?
>>> import pytz
>>> i.timezone
'America/Chicago'
>>> pytz.timezone(i.timezone)
>>> ot
datetime.datetime(2016, 3, 14, 9, 30, tzinfo=)
>>> ot.tzinfo
Shouldn't the America/Chicago timezone reflect DST?
Thx,
Skip
--
https://mail.python.or
bably neither better nor worse than Python. All one has to do is set
>>> the TZ environment variable, eg (untested):
>>>
>>> _year_gmt=$( TZ=GMT date +%Y )
>>
>> That's assuming that it's converting against the current system
>> timezone. I d
t; the TZ environment variable, eg (untested):
>>
>> _year_gmt=$( TZ=GMT date +%Y )
>
> That's assuming that it's converting against the current system
> timezone. I don't know how you'd use `date` to convert between two
> arbitrary timezones. […]
W
On Mon, 6 Oct 2014 13:48:58 +1100, Chris Angelico
wrote:
>On Mon, Oct 6, 2014 at 1:37 PM, Rustom Mody wrote:
>>> My advice is to avoid time zones, they're a real pain, seriously.
>>
>> What say we send an application to the UN to declare the world flat?
>
>Easier to simply start scheduling thing
On Mon, Oct 6, 2014 at 1:37 PM, Rustom Mody wrote:
>> My advice is to avoid time zones, they're a real pain, seriously.
>
> What say we send an application to the UN to declare the world flat?
Easier to simply start scheduling things in UTC. I run an
international Dungeons & Dragons campaign with
On Monday, October 6, 2014 3:45:44 AM UTC+5:30, Mark Lawrence wrote:
> On 05/10/2014 22:17, Seymore4Head wrote:
> > This is not a new video, but it is new to me.
> > https://www.youtube.com/watch?v=-5wpm-gesOY
> > Any links to some easy to follow time zone math?
> My advice is to avoid time zones,
he tz database to convert between timezones (many people
get it wrong but it is not a rocket science). As said in the video, it
won't help if the rules change a day before the DST transition but at
least most [1] systems will be consistent. It also doesn't support
some exotic timezone ru
On 05/10/2014 22:17, Seymore4Head wrote:
This is not a new video, but it is new to me.
https://www.youtube.com/watch?v=-5wpm-gesOY
Any links to some easy to follow time zone math?
My advice is to avoid time zones, they're a real pain, seriously.
--
My fellow Pythonistas, ask not what our lan
This is not a new video, but it is new to me.
https://www.youtube.com/watch?v=-5wpm-gesOY
Any links to some easy to follow time zone math?
--
https://mail.python.org/mailman/listinfo/python-list
On Fri, Jan 31, 2014 at 1:26 PM, Ben Finney wrote:
> He also reinforces the message that UTC is the canonical timezone for
> storing and manipulating timestamp values, and we should be converting
> to/from those canonical values as early/late as possible in our programs.
Call it a "UTC Sandwich",
Ben Finney writes:
> Time zones are a hairy beast to manage, made all the more difficult
> because national politicians continually fiddle with them which means
> they can't just be a built-in part of the Python standard library.
PyCon 2013 had a good talk on calendaring and timezone issues
http
The default converter attribute uses localtime, but often under windows when
I add an additional logger, create a new file handler and set a formatter the
time
switches to utc.
Obviously redefining a new converter class does nothing as the default is what I
wanted to start with, localtime.
Anyon
On 10/23/2013 12:00 PM, Skip Montanaro wrote:
>
--> LOCAL_TZ.localize(dt1).utcoffset()
datetime.timedelta(-1, 68400)
--> LOCAL_TZ.localize(dt2).utcoffset()
datetime.timedelta(-1, 64800)
Why is the UTC offset the same for both datetime objects despite the
presence/absence of Daylight Savings?
LOCAL_TZ.localize(dt1).utcoffset()
> datetime.timedelta(-1, 68400)
LOCAL_TZ.localize(dt2).utcoffset()
> datetime.timedelta(-1, 64800)
>
> Why is the UTC offset the same for both datetime objects despite the
> presence/absence of Daylight Savings?
Brain freeze! A quick glance told me they
This isn't really a Python issue, though my problem solution will be
implemented in Python. If I have a naive datetime object for some time
in the past, it's not clear to me how the offset gets set correctly.
Consider this sequence:
>>> import datetime, pytz
>>> LOCAL_TZ = pytz.timezone(os.environ
> [1] http://pypi.python.org/pypi/PosixTimeZone/0.9.4
> [2] http://pypi.python.org/pypi/pytz/2011g
> [3] http://docs.python.org/library/datetime.html#tzinfo-objects
Also
http://labix.org/python-dateutil#head-587bd3efc48f897f55c179abc520a34330ee0a62
HTH
--
Miki Tebeka
http://pythonwise.blogspot.c
On Mon, May 23, 2011 at 10:56 PM, loial wrote:
> Thanks...but being a python newbie I am struggling to understand how
> to do this.
>
> How can I use tzinfo to do the equivalent of what I do in Java, which
> is :
>
>TimeZone tz1 = TimeZone.getDefault();
>
>long localOffset = tz1.getOffset
("EST");
long remoteOffset = tz2.getOffset(date.getTime());
Any help appreciated
On May 23, 11:48 am, Daniel Kluev wrote:
> On Mon, May 23, 2011 at 9:32 PM, loial wrote:
> > Does python have an equivalent of the java Timezone object?
>
> > I need to be able
On Mon, May 23, 2011 at 9:32 PM, loial wrote:
> Does python have an equivalent of the java Timezone object?
>
> I need to be able to get offsets for timezones (only U.S. time zones
> at the moment)
Depends on what exactly do you want. If you need to convert timezone
name into current
Does python have an equivalent of the java Timezone object?
I need to be able to get offsets for timezones (only U.S. time zones
at the moment)
--
http://mail.python.org/mailman/listinfo/python-list
A script that I'm writing pulls the system time off of an iPod
connected to the computer. The iPod's time is represented as a Unix
timestamp (seconds since the epoch), but this timestamp does not
represent UTC time, but rather the local timezone of the owner. I need
to convert this local time times
Here's some Python code executed on Red Hat 3.4 web server located in
Mountain time (MDT). You'll notice that the time after setting the
timezone to Eastern time (EST), the time is incorrectly 6 hours ahead,
when it should only be 3.
Python 2.5 (r25:51908, Mar 23 2007, 14:22:20)
[GCC 3.4.6 200604
The wonderful thing about RFC 1123 timestamps is that they give the
numeric value of their timezone, so you don't have to decode a symbolic
one or anything like that. Knowing about timezones thus isn't necessary.
The problem is simply that the standard time package doesn't think
Tom Anderson wrote:
Secondly, do you really have to do this just to parse a date with a
timezone? If so, that's ridiculous.
No, you don't. :) Download the pytz package from the Python package
index. It's *the* tool for timezone handling in Python. The time zone
definition are not part of the
Hello!
Possibly i'm missing something really obvious here. But ...
If i have a date-time string of the kind specified in RFC 1123, like this:
Tue, 12 Aug 2008 20:48:59 -0700
Can i turn that into a seconds-since-the-epoch time using the standard
time module without jumping through substantial
pastebin.ca/1061776
>
> On Jul 2, 11:22 am, Mensanator <[EMAIL PROTECTED]> wrote:
>
> > On Jul 2, 12:43 am, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote:
>
> > > I'm trying to write some code to deal with world timezones, and I'm
> > &g
l 2, 11:22 am, Mensanator <[EMAIL PROTECTED]> wrote:
> On Jul 2, 12:43 am, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote:
>
>
>
> > I'm trying to write some code to deal with world timezones, and I'm
> > getting a strange result. America/Iqaluit s
On Jul 2, 12:43 am, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote:
> I'm trying to write some code to deal with world timezones, and I'm
> getting a strange result. America/Iqaluit should not be showing up in
> UTC+00:00, but it is. Can anyone see what'
I'm trying to write some code to deal with world timezones, and I'm
getting a strange result. America/Iqaluit should not be showing up in
UTC+00:00, but it is. Can anyone see what's wrong with this code?
import time
from datetime import datetime
import os
i
On 5 Dec, 13:59, "Gabriel Genellina" <[EMAIL PROTECTED]> wrote:
> En Wed, 05 Dec 2007 06:43:49 -0300, <[EMAIL PROTECTED]> escribió:
>
> > Thanks guys for your answers! I know those library's but I was
> > wondering is there something build-in for this simple convert convert.
> > I have to do it onl
En Wed, 05 Dec 2007 06:43:49 -0300, <[EMAIL PROTECTED]> escribió:
> Thanks guys for your answers! I know those library's but I was
> wondering is there something build-in for this simple convert convert.
> I have to do it only from +4 to +0.
Copying the example from the tzinfo docs:
from dateti
Thanks guys for your answers! I know those library's but I was
wondering is there something build-in for this simple convert convert.
I have to do it only from +4 to +0.
--
http://mail.python.org/mailman/listinfo/python-list
[EMAIL PROTECTED] wrote:
> Is there any build in solution in python to handle timezones? My
> problem is I have to convert +4 time to +0. In the worst case i can
> just add +4 to the houer but I'm not very happy about that. Another
> problem is the summer/winter timechange whic
[EMAIL PROTECTED] wrote:
> Is there any build in solution in python to handle timezones? My
> problem is I have to convert +4 time to +0. In the worst case i can
> just add +4 to the houer but I'm not very happy about that. Another
> problem is the summer/winter timechange whic
Hello,
Is there any build in solution in python to handle timezones? My
problem is I have to convert +4 time to +0. In the worst case i can
just add +4 to the houer but I'm not very happy about that. Another
problem is the summer/winter timechange which happen with one week
difference.
On 10/10/07, Sanjay <[EMAIL PROTECTED]> wrote:
> Thanks a lot, Guys. The immediate step I think to take is having two
> combo boxes (dividing the data by '/'). Thanks for enormous response
> and the valuable suggestions!
The most elegant way I've seen to handle this in a graphical interface
(eithe
Thanks a lot, Guys. The immediate step I think to take is having two
combo boxes (dividing the data by '/'). Thanks for enormous response
and the valuable suggestions!
Sanjay
--
http://mail.python.org/mailman/listinfo/python-list
I apologize for being a dick. It won't happen again.
I was actually thinking that the 25 standard
timezones (which make a reasonable list or
can be easily generated by clicking a map)
could serve as a filter to make the detail
list reasonably sized.
Something like this:
import pytz
i
>> who says that timezones have to be separated by one hour each?
>
> The Earth says. It takes 24 hours to revolve.
Your kidding me, aren't you? Beside the fact that the earth does not
revolve in 24h (leap seconds, if you like to google), even the 24 hours
of a day are as
>> who says that timezones have to be separated by one hour each?
>
> The Earth says. It takes 24 hours to revolve.
Wrong
>> Why aren't they separated by 30minutes, or 20, or 10? Or 2 hours?
>
> Why isn't an hour defined to be 30 minutes?
>
>> Or why
ting your clock.
> >
> > That's BS. If I'm supposed to be attending a video-conference that spans a
> > few continents which is scheduled using a web-app, it's VITAL that I get
> > the invitation and reminder rendered in MY local timezone, DST included.
>
On 10/9/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> > Why aren't they separated by 30minutes, or 20, or 10? Or 2 hours?
>
> Why isn't an hour defined to be 30 minutes?
>
> > Or why don't we have a global time?
>
> Like UTC?
>
> >
>
On Tue, Oct 09, 2007 at 11:21:41AM -0700, [EMAIL PROTECTED] wrote regarding Re:
pytz has so many timezones!:
>
> The Earth says. It takes 24 hours to revolve.
>
> > Why aren't they separated by 30minutes, or 20, or 10? Or 2 hours?
>
> Why isn't an hour defined
hey are all GMT-6
>
> >> But they could have different rules for Daylight Saving Time.
>
> > Which only matters if you're setting your clock.
>
> That's BS. If I'm supposed to be attending a video-conference that spans a
> few continents which is schedule
1 - 100 of 133 matches
Mail list logo
