hello django-users hope you are doing well !
I was trying to convert the Date from string to timestamp
def JsonDeliv(request):
dataset = DeliveriesperDate.objects.all().values_list('Date',
'CountDeliveries')
data = list(dataset)
for i in data :
data[i][0] = int(time.mktime(time.strpti
Tom, thank you for that very useful tip! My feeble python-fu has now been
strengthened.
On Monday, December 17, 2012 8:27:28 AM UTC-6, Tom Evans wrote
>
>
> Following the thread I see that you have figured out where and why
> this is coming from. There is a simple tip you can use to speed this
On Fri, Dec 14, 2012 at 5:46 PM, bobhaugen wrote:
> RuntimeWarning: DateTimeField received a naive datetime (2012-12-14
> 17:39:38.878379) while time zone support is active.
>
> This is happening in my tests, but not in normal code.
>
> From dropping a trace in, it looks like it is happening befor
Awesome. Thanks for the update.
On Sunday, December 16, 2012 3:56:22 AM UTC-8, bobhaugen wrote:
>
> Wrapping this up: the problem was caused by South, happened in migrate
> (found via stack trace). When I upgraded South, the problem went away.
--
You received this message because you are subs
Wrapping this up: the problem was caused by South, happened in migrate
(found via stack trace). When I upgraded South, the problem went away.
--
You received this message because you are subscribed to the Google Groups
"Django users" group.
To view this discussion on the web visit
https://gr
Ok, got a friend to try this using python2.7 and did not get the naive
datetime warnings.
So I conclude it is something about either python2.6 or something else
in my local environment, and not a proper django-users concern.
P.S. Chris, thanks again for all the help. You're really active
respond
On Sat, Dec 15, 2012 at 1:16 AM, Chris Cogdon wrote:
> I never got the warnings you got, but I got three errors along the lines of:
> IntegrityError: valueaccounting_economicagent.created_date may not be NULL
> Want me to grab a different revision from git ?
Fixed that one. You could do a git p
Well, I did all that (and I learned a few things in the process that will
be useful for my own project... thank you!)
I never got the warnings you got, but I got three errors along the lines of:
==
ERROR: test_mismatched_agents1
Also, I recognize this is way beyond the call of duty, but if you
really want to reproduce the problem, you might need to follow:
https://github.com/valnet/valuenetwork/blob/master/docs/install.txt
On Fri, Dec 14, 2012 at 7:06 PM, Chris Cogdon wrote:
> Checked out the code and attempted to run "m
I'm running ./manage.py test valueaccounting
--
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to
django-users+unsubscr...@googlegroups
Checked out the code and attempted to run "manage.py test", but clearly I
don't have all the required modules installed. Sure is a lot of them!
Are you running tests using "manage.py test" ?? If so, have you considered
that its not _your_ code that is showing up those errors, but that of one
o
On Fri, Dec 14, 2012 at 6:07 PM, Chris Cogdon wrote:
> Throw the code up somewhere I can see the results for myself?
https://github.com/valnet/valuenetwork/blob/master/valuenetwork/valueaccounting/tests.py
--
You received this message because you are subscribed to the Google Groups
"Django use
Throw the code up somewhere I can see the results for myself?
On Friday, December 14, 2012 3:52:11 PM UTC-8, bobhaugen wrote:
>
> But sincerely, Chris, thanks for hanging in there on this. I baffled.
>
> On Fri, Dec 14, 2012 at 5:51 PM, Bob Haugen >
> wrote:
> > On Fri, Dec 14, 2012 at 5:42 PM
But sincerely, Chris, thanks for hanging in there on this. I baffled.
On Fri, Dec 14, 2012 at 5:51 PM, Bob Haugen wrote:
> On Fri, Dec 14, 2012 at 5:42 PM, Chris Cogdon wrote:
>> Okay, so when you create your datetimes, are you defining them with a
>> timezone ?
>
> I tried that; did not make a
On Fri, Dec 14, 2012 at 5:42 PM, Chris Cogdon wrote:
> Okay, so when you create your datetimes, are you defining them with a
> timezone ?
I tried that; did not make any difference. The error messages came up
before any of the test setup code ran. (I put a pdb trace in at the
start; the error me
Okay, so when you create your datetimes, are you defining them with a
timezone ?
On Friday, December 14, 2012 1:05:19 PM UTC-8, bobhaugen wrote:
>
> On Fri, Dec 14, 2012 at 3:02 PM, Chris Cogdon >
> wrote:
> > Nothing definitive, but from checking the location of the code that is
> > raising t
On Fri, Dec 14, 2012 at 3:02 PM, Chris Cogdon wrote:
> Nothing definitive, but from checking the location of the code that is
> raising the warning, I suspect one of the following:
>
> 1. USE_TZ is not set in your production code, but _is_ set in your settings
> file for your tests. Of course, you
Nothing definitive, but from checking the location of the code that is
raising the warning, I suspect one of the following:
1. USE_TZ is not set in your production code, but _is_ set in your settings
file for your tests. Of course, your code should work either way for the
most flexibility.
2.
Oh, and Django 1.4.1...sorry.
On Friday, December 14, 2012 1:43:09 PM UTC-6, bobhaugen wrote:
>
> Thanks for the reply.
>
> On Friday, December 14, 2012 1:27:03 PM UTC-6, Chris Cogdon wrote:
>>
>> Would be nice to know what function's raising that error, and where the
>> value came from. Requesti
Thanks for the reply.
On Friday, December 14, 2012 1:27:03 PM UTC-6, Chris Cogdon wrote:
>
> Would be nice to know what function's raising that error, and where the
> value came from. Requesting traceback, database type (tried it with more
> than one database type), and other information.
>
> It
Would be nice to know what function's raising that error, and where the
value came from. Requesting traceback, database type (tried it with more
than one database type), and other information.
On Friday, December 14, 2012 9:46:33 AM UTC-8, bobhaugen wrote:
>
> RuntimeWarning: DateTimeField rece
RuntimeWarning: DateTimeField received a naive datetime (2012-12-14
17:39:38.878379) while time zone support is active.
This is happening in my tests, but not in normal code.
>From dropping a trace in, it looks like it is happening before the test
setup even runs.
I double-checked my models,
Hi guys,
I'm facing strange problems with dates in django. I have an object
list called from a view with the following code is
...
now = datetime.datetime.now()
period_limit = now - datetime.timedelta(days=30)
queryset = queryset.filter(
item__pub_date__lte=now, # no future items
item_
It is possible, that the clock on the server is set differently than
the clock on your local machine. Have you checked that?
Good luck!
Aidas Bendoraitis aka Archatas
On 10/26/06, 张沈鹏 <[EMAIL PROTECTED]> wrote:
>
> I set
>
> TIME_ZONE = 'CCT'
> (in China)
>
> and
> use
> uploadBeginFrom = m
I set
TIME_ZONE = 'CCT'
(in China)
and
use
uploadBeginFrom = models.DateTimeField ('begin
time',default=datetime.now())
then the time in admin defalut value is "01:29:57"
but the time now actually is "9:33:17"
>>> datetime.now()
datetime.datetime(2006, 10, 26, 9, 33, 17, 942000)
--~
25 matches
Mail list logo
