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
On Mon, Feb 10, 2020 at 05:52:59PM -0600, Skip Montanaro 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
> 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.
>
...
> Does Python have an a
On 2019-12-11 10:51 PM, Skip Montanaro wrote:
Why is a dtm instance also an instance of dt?
The datetime type is, in fact, a subclass of the date type:
import datetime
datetime.date.__bases__
(,)
datetime.datetime.__bases__
(,)
datetime.time.__bases__
(,)
Skip
Thanks for that.
I fou
> Why is a dtm instance also an instance of dt?
The datetime type is, in fact, a subclass of the date type:
>>> import datetime
>>> datetime.date.__bases__
(,)
>>> datetime.datetime.__bases__
(,)
>>> datetime.time.__bases__
(,)
Skip
--
https://mail.python.org/mailman/listinfo/python-list
... so you decided to start the post already hijacked by yourself ...
very clever!!
On Friday, August 5, 2016 at 8:19:53 PM UTC-4, bream...@gmail.com wrote:
> On Friday, August 5, 2016 at 7:15:37 PM UTC+1, DFS wrote:
> > On 8/4/2016 6:41 PM, breamore...@gmail.com wrote:
> > > Fascinating stuff h
On Fri, 5 Aug 2016 08:41 am, breamore...@gmail.com wrote:
> I hereby ask that only people who know and use Python reply, not the
> theoretical idiots who could not fight their way out of a wet paper bag.
So it's only people who are theoretically idiots that are prohibited from
replying? Actual,
Alexander Belopolsky writes:
> No credit for anything other than the "extra credit" section. Partial
> credit for that. Study that printout and you should understand what
> Tim was saying.
My original claim was that the pickler can't know and doesn't care if a
byte string value merely happens
[Tim]
>> Sorry, I'm not arguing about this any more. Pickle doesn't work at
>> all at the level of "count of bytes followed by a string".
[Random832 ]
> The SHORT_BINBYTES opcode consists of the byte b'C', followed by *yes
> indeed* "count of bytes followed by a string".
Yes, some individual opc
On Mon, Sep 14, 2015, at 18:09, Tim Peters wrote:
> Sorry, I'm not arguing about this any more. Pickle doesn't work at
> all at the level of "count of bytes followed by a string".
The SHORT_BINBYTES opcode consists of the byte b'C', followed by *yes
indeed* "count of bytes followed by a string".
On Monday, September 14, 2015 at 5:23:32 PM UTC-6, Laura Creighton wrote:
>[...]
> I don't know about the others, but I am finding this rather more
> entertaining than another round of 'python -- does it have pointers'
> in python-list.
Could we please dispense with the gratuitous "what I'm intere
On Mon, Sep 14, 2015, at 16:01, Carl Meyer wrote:
>> Can we please stop cross-posting this thread to python-list and move it
>> to datetime-sig only? I think anyone here on python-list who is
>> sufficiently interested in it can subscribe to datetime-sig.
>>
>> Or the other way around, whatever. I
In a message of Mon, 14 Sep 2015 15:35:28 -0400, Random832 writes:
>As far as I know, the position of the tzdata people is that while this
>belief is held almost everywhere that does not observe DST but is
>surrounded by places that do (I should know; I live in Indiana, which
>was such a place unti
[Random832 ]
> Would allowing a 16-byte string in the future have increased the storage
> occupied by a 10-byte string today? Would allowing a third argument in
> the future have increased the storage occupied by two arguments today?
> As far as I can tell the pickle format for non-primitive types
On Mon, Sep 14, 2015, at 17:34, Tim Peters wrote:
> Yes, we "could have" done that for all pickle formats for all types.
> But why on Earth would we? Pickle size is important to many apps
> (e.g., Zope applications can store billions of pickles in databases.
> and it may not be purely coincidence
[Tim]
>> Because all versions of Python expect a very specific pickle layout
>> for _every_ kind of pickled object (including datetimes).. Make any
>> change to the pickle format of any object, and older Pythons will
>> simply blow up (raise an exception) when trying to load the new pickle
>> - or
On Mon, Sep 14, 2015, at 16:45, Tim Peters wrote:
> Because all versions of Python expect a very specific pickle layout
> for _every_ kind of pickled object (including datetimes).. Make any
> change to the pickle format of any object, and older Pythons will
> simply blow up (raise an exception) wh
On Mon, Sep 14, 2015 at 4:22 PM, Tim Peters wrote:
> > faster
> > than CPython can look up the .utcoffset method. (At least for times
> > within a few years around now.) A programmer who makes it slower should
> > be fired.
>
> So any programmer who implements .utcoffset() in Python should be
> f
On Mon, Sep 14, 2015 at 3:49 PM, Tim Peters wrote:
> It depends on how expensive .utcoffset()
> is, which in turn depends on how the tzinfo author implements it.
>
No, it does not. In most time zones, UTC offset in seconds can be computed
by C code as a 4-byte integer faster than CPython can lo
On Mon, Sep 14, 2015 at 3:44 PM, Random832 wrote:
> It is an
> invariant that is true today, and therefore which you can't rely on any
> of the consumers of this 12 years old widely deployed code not to assume
> will remain true.
>
Sorry, this sentence does not parse. You are missing a "not" so
On Mon, Sep 14, 2015 at 4:08 PM, Random832 wrote:
> On Mon, Sep 14, 2015, at 15:48, Alexander Belopolsky wrote:
> > On Mon, Sep 14, 2015 at 3:44 PM, Random832
> > wrote:
> >
> > > It is an
> > > invariant that is true today, and therefore which you can't rely on any
> > > of the consumers of thi
[Random832 ]
> A) I'm still not sure why, but I was talking about adding an int, not a
> timedelta and a string.
>
> B) Older python versions can't make use of either utcoffset or fold, but
> can ignore either of them. I don't even see why they couldn't ignore a
> timedelta and a string if we felt
On Mon, Sep 14, 2015, at 16:15, Tim Peters wrote:
> [Random832 ]
>
> Whether or not datetimes stored tm_gmtoff and tm_zone workalikes has
> no effect on semantics I can see. If, in your view, they're purely an
> optimization, they're just a distraction for now. If you're proposing
> to add them
[Tim]
>> It depends on how expensive .utcoffset()
>> is, which in turn depends on how the tzinfo author implements it.
[Alex]
> No, it does not. In most time zones, UTC offset in seconds can be computed
> by C code as a 4-byte integer
Which is a specific implementation of .utcoffset(). Which li
[Random832 ]
Whether or not datetimes stored tm_gmtoff and tm_zone workalikes has
no effect on semantics I can see. If, in your view, they're purely an
optimization, they're just a distraction for now. If you're proposing
to add them _instead_ of adding `fold`, no, that can't work, for the
pick
On Mon, Sep 14, 2015, at 16:01, Carl Meyer wrote:
> Can we please stop cross-posting this thread to python-list and move it
> to datetime-sig only? I think anyone here on python-list who is
> sufficiently interested in it can subscribe to datetime-sig.
>
> Or the other way around, whatever. I'd ju
On Mon, Sep 14, 2015, at 15:48, Alexander Belopolsky wrote:
> On Mon, Sep 14, 2015 at 3:44 PM, Random832
> wrote:
>
> > It is an
> > invariant that is true today, and therefore which you can't rely on any
> > of the consumers of this 12 years old widely deployed code not to assume
> > will remain
Can we please stop cross-posting this thread to python-list and move it
to datetime-sig only? I think anyone here on python-list who is
sufficiently interested in it can subscribe to datetime-sig.
Or the other way around, whatever. I'd just like to stop getting all the
messages twice.
Carl
sig
On Mon, Sep 14, 2015, at 15:30, Tim Peters wrote:
> You're assuming much more than POSIX - and the ISO C standard -
> requirs. My description was quite explicitly about how POSIX has done
> it all along. tm_gmtoff and tm_zone are extensions to the standards,
> introduced (IIRC) by BSD. Portable
On Mon, Sep 14, 2015, at 15:25, Alexander Belopolsky wrote:
> This is a fine attitude when you implement your own brand new datetime
> library. As an author of a new library you have freedoms that developers
> of a 12 years old widely deployed code don't have.
I'm talking about the real behavior
[Tim]
>> It would be nice to have! .utcoffset() is an expensive operation
>> as-is, and being able to rely on tm_gmtoff would make that dirt-cheap
>> instead.
[Alex]
> If it is just a question of optimization,
Yes. If it's more than just that, then 495 doesn't actually solve the
problem of get
On Mon, Sep 14, 2015 at 3:13 PM, Random832 wrote:
> (No, I don't
> *care* how that's not how it's defined, it is *in fact* true for the UTC
> value that you will ever actually get from converting the values to UTC
> *today*, and it's the only total ordering that actually makes any sense)
>
This
On Mon, Sep 14, 2015 at 3:30 PM, Tim Peters wrote:
> > make it much cheaper to maintain global invariants like a sort order
> > according to the UTC value
>
> It would be nice to have! .utcoffset() is an expensive operation
> as-is, and being able to rely on tm_gmtoff would make that dirt-cheap
On Mon, Sep 14, 2015, at 04:53, Laura Creighton wrote:
> But this is not quite the complete story. In many (most?) places in
> Saskatchewan, the rule is understood differently. Instead of 'we keep
> to CST all year long' is is understood that 'we keep central time in
> the winter and mountain ti
[Tim]
>> So, on your own machine, whenever daylight time starts or ends, you
>> manually change your TZ environment variable to specify the newly
>> appropriate eternally-fixed-offset zone? Of course not.
[Random832 ]
> No, but the hybrid zone isn't what gets attached to the individual
> struct t
[Guido]
>> Wouldn't it be sufficient for people in Creighton to set their timezone to
>> US/Central? IIUC the Canadian DST rules are the same as the US ones. Now,
>> the question may remain how do people know what to set their timezone to.
>> But neither pytz nor datetime can help with that -- it i
On Mon, Sep 14, 2015, at 14:53, Tim Peters wrote:
> So, on your own machine, whenever daylight time starts or ends, you
> manually change your TZ environment variable to specify the newly
> appropriate eternally-fixed-offset zone? Of course not.
No, but the hybrid zone isn't what gets attached to
[Tim]
>> pytz solves it by _never_ creating a hybrid tzinfo. It only uses
>> eternally-fixed-offset tzinfos. For example, for a conceptual zone
>> with two possible total UTC offsets (one for "daylight", one for
>> "standard"), there two distinct eternally-fixed-offset tzinfo objects
>> in pytz.
In a message of Mon, 14 Sep 2015 09:30:43 -0400, Random832 writes:
>On Mon, Sep 14, 2015, at 04:27, Laura Creighton wrote:
>> I find this totally unacceptable. My conclusion was that hybrid tzinfo
>> objects were a _really stupid idea_ proposed by somebody who
>> misunderstood
>> the problem, or r
On Mon, Sep 14, 2015, at 04:27, Laura Creighton wrote:
> I find this totally unacceptable. My conclusion was that hybrid tzinfo
> objects were a _really stupid idea_ proposed by somebody who
> misunderstood
> the problem, or rather only understood the most common case.
"Hybrid tzinfo objects" _in
In a message of Sun, 13 Sep 2015 15:21:45 -0700, Guido van Rossum writes:
>Hi Laura!
>
>Wouldn't it be sufficient for people in Creighton to set their timezone to
>US/Central? IIUC the Canadian DST rules are the same as the US ones. Now,
>the question may remain how do people know what to set their
In a message of Sun, 13 Sep 2015 16:58:09 -0500, Tim Peters writes:
>[Tim]
>>> Whatever time zone the traveler's railroad schedule uses, so long as
>>> it sticks to just one
>
>[Laura]
>> This is what does not happen. Which is why I have written a python
>> app to perform conversions for my parent
On Sun, Sep 13, 2015 at 6:21 PM, Guido van Rossum wrote:
>
> Now, the question may remain how do people know what to set their
timezone to. But neither pytz nor datetime can help with that -- it is up
to the sysadmin.
Note that this question is also out of the scope of "tzdist", IETF Time
Zone D
[Guido]
> Wouldn't it be sufficient for people in Creighton to set their timezone to
> US/Central? IIUC the Canadian DST rules are the same as the US ones. Now,
> the question may remain how do people know what to set their timezone to.
> But neither pytz nor datetime can help with that -- it is up
On Sun, Sep 13, 2015 at 5:24 AM, Laura Creighton wrote:
> My question, is whether it will handle Creighton, Saskatchewan, Canada?
> Creighton is an odd little place. Like all of Saskatchewan, it is
> in the Central time zone, even though you would expect it to be
> in the Mountain time zone base
[Tim]
>> Whatever time zone the traveler's railroad schedule uses, so long as
>> it sticks to just one
[Laura]
> This is what does not happen. Which is why I have written a python
> app to perform conversions for my parents, in the past.
So how did they get the right time zone rules for Creighto
In a message of Sun, 13 Sep 2015 15:13:53 -0500, Tim Peters writes:
>[Laura]
>> Via Rail will give you a schedule when you book your tickets. But I
>> am wrong, it gives it to you in local time, which you can scrape or
>> even use the via rail api. So it is the person getting off in
>> Creighton
[Laura]
>>> But I am not sure how it is that a poor soul who just wants to print a
>>> railway schedule 'in local time' is supposed to know that Creighton is
>>> using Winnipeg time.
[Tim]
>> I'm not sure how that poor soul would get a railway schedule
>> manipulable in Python to begin with ;-)
[
In a message of Sun, 13 Sep 2015 14:00:33 -0500, Tim Peters writes:
>> But I am not sure how it is that a poor soul who just wants to print a
>> railway schedule 'in local time' is supposed to know that Creighton is
>> using Winnipeg time.
>
>I'm not sure how that poor soul would get a railway sche
[Tim]
>> Hi, Laura! By "zoneinfo" here, we mean the IANA (aka "Olson") time
>> zone database, which is ubiquitous on (at least) Linux:
>>
>>https://www.iana.org/time-zones
>>
>>So "will a wrapping of zoneinfo handle XYZ?" isn't so much a question
>>about the wrapping as about what's in the IAN
Laura Creighton writes:
> But I am not sure how it is that a poor soul who just wants to print a
> railway schedule 'in local time' is supposed to know that Creighton is
> using Winnipeg time.
The same way they know that any other location is using whatever time it
uses. By the user having specif
In a message of Sun, 13 Sep 2015 10:27:30 -0500, Tim Peters writes:
>Hi, Laura! By "zoneinfo" here, we mean the IANA (aka "Olson") time
>zone database, which is ubiquitous on (at least) Linux:
>
>https://www.iana.org/time-zones
>
>So "will a wrapping of zoneinfo handle XYZ?" isn't so much a qu
[Alex]
>>I will try to create a zoneinfo wrapping prototype as well, but I will
>>probably "cheat" and build it on top of pytz.
[Laura Creighton]
> My question, is whether it will handle Creighton, Saskatchewan, Canada?
> Creighton is an odd little place. Like all of Saskatchewan, it is
> in the
In a message of Sat, 12 Sep 2015 22:15:02 -0400, Alexander Belopolsky writes:
>I completely agree. That's why I am adding test cases like Lord Hope
>Island and Vilnius to datetimetester.
>
>I will try to create a zoneinfo wrapping prototype as well, but I will
>probably "cheat" and build it on to
On Sat, Sep 12, 2015, at 22:25, Tim Peters wrote:
> That helps a lot, but "industrial-strength" implies "by algorithm".
> There are far too many zones to deal with by crafting a hand-written
> class for each.
It occurs to me that though it's written in C, the zdump utility
included in the tz cod
On Sat, Sep 12, 2015 at 10:25 PM, Tim Peters wrote:
> > I will try to create a zoneinfo wrapping prototype as well, but I will
> > probably "cheat" and build it on top of pytz.
>
> It would be crazy not to ;-) Note that Stuart got to punt on "the
> hard part": .utcoffset(), since pytz only use
On Sat, Sep 12, 2015 at 6:24 PM, Guido van Rossum wrote:
> The repeated claims (by Alexander?) that astimezone() has the power of
> pytz's localize() need to stop.
Prove me wrong! :-)
> Those pytz methods work for any (pytz) timezone -- astimezone() with a
> default argument only works for th
On Sat, Sep 12, 2015 at 9:58 PM, Tim Peters wrote:
> > That's why I believe PEP 495 followed by the implementation
> > of fold-aware "as intended" tzinfos (either within stdlib or by third
> > parties) is the right approach.
>
> Me too - except I think acceptance of 495 should be contingent upon
[Alex]
>>> I will try to create a zoneinfo wrapping prototype as well, but I will
>>> probably "cheat" and build it on top of pytz.
[Tim]
>> It would be crazy not to ;-) Note that Stuart got to punt on "the
>> hard part": .utcoffset(), since pytz only uses fixed-offset classes.
>> For a prototy
[Tim]
>> Me too - except I think acceptance of 495 should be contingent upon
>> someone first completing a fully functional (if not releasable)
>> fold-aware zoneinfo wrapping.
[Alex]
> Good idea. How far are you from completing that?
In my head, it was done last week ;-) In real life, I'm runn
On Sat, Sep 12, 2015 at 5:46 PM, Alexander Belopolsky <
alexander.belopol...@gmail.com> wrote:
>
> On Sat, Sep 12, 2015 at 6:24 PM, Guido van Rossum
> wrote:
>
>> The repeated claims (by Alexander?) that astimezone() has the power of
>> pytz's localize() need to stop.
>
>
> Prove me wrong! :-)
>
1 - 100 of 322 matches
Mail list logo
