Thanks for filing! Will try to get to it soon

Hi @insajd

1. What browser are you using?
2. Is your timezone set in your user profile? Currently, you can only change it from the app while creating an account, but you should be able to check with the django admin.

1. Chrome desktop Version 47.0.2526.106 m (64-bit)
2. Yes, my user has set up Europe/Riga timezone as I see when I open Sqlite Db. First user I created had different timezone.

I checked IE, Firefox - same as in Chrome.
Network calls show that when selecting 22 Dec-22 Dec the request to server is sent like this:
http://[webaddr]/api/transactions/?fromDate=2015-12-21T22:00:00.000Z&toDate=2015-12-21T22:00:00.000Z
Currently it's 2015-12-21 16:48 where I live

Thanks for the info. That should be more than enough to recreate it, without needing to visit.

Sorry, @DoomHammer, I'm going to have to find another excuse to get drunk in Poland with you.

No worries 🍹

OK. I'm not sure if I fixed this, so you'll have to test some more. I had a lot of things going on with datetime and I think it will be easier to narrow down the issue.

1. I added a debug footer.
2. I removed the datetime service. I don't think it was actually doing anything and maybe native javascript datetimes are the way to go.

If it continues to be an issue, take a screenshot of that footer and your system clock and included the relevant api calls.

Hi,

It seems to be still and issue. Curently, both the logs, and the client are same computer.


At first screenshot I clicked FROM field, selected TODAY. Then I clicked TO field(2nd request) and selected again TODAY.
On the second screenshot I show the footer of the web page.

at 2 AM my local time(Riga/Latvia) I saw result of my cron job with daily transaction rate which was configured with your latest commits. cron job is run with command 0 * * * * /usr/bin/python /home/olegs/dev/manage.py transact

Alrighty. I figured there was a good chance this was still an issue. The
new footer should make it easier to debug. I'll try something different.
Thanks for the reply.

On Fri, Jan 8, 2016, 6:18 PM insajd notifications@github.com wrote:

at 2 AM my local time(Riga/Latvia) I saw result of my cron job with daily
transaction rate which was configured with your latest commits. cron job is
run with command 0 * * * * /usr/bin/python /home/olegs/dev/manage.py
transact

—
Reply to this email directly or view it on GitHub
#62 (comment).

Can you enter Date() in the chrome debugger and attach the output?
With the new build, that is the only thing that happens before you hit the API. The params should be coming out of the browser.

Here goes the output Date()
"Sat Jan 09 2016 09:53:38 GMT+0200 (EET)"

Hi, I still have a problem on my new fresh setup. I will give you access to my setup with source, where it all works that weird way.

I was wondering if this was an issue. I think I have an idea for how to fix it.
I'm going to attempt it in a VM.

Thanks for your patience!

I mentioned that cron for my user worked at 2 AM, but latest version from master branch actually doesn't has this problem.
I only have problem with filters on web page, when filtering for specific dates.

Ah. Awesome. That means we're getting closer.

On Mon, Feb 8, 2016 at 2:46 AM, insajd notifications@github.com wrote:

I mentioned that cron for my user worked at 2 AM, but latest version from
master branch actually doesn't has this problem.
I only have problem with filters on web page, when filtering for specific
dates.

—
Reply to this email directly or view it on GitHub
#62 (comment).

I've been meaning to try Bennedetto myself for some time and since I'm also in the EU, I was wondering which branch would be currently the one to use - master or timezone-refactor?

@rainforest1155
The timezone-refactor branch is definitely not ready yet. If anything use master.
I have a working theory about the date filters. I think it is only an issue when the date is prepopulated. I would be grateful if you could experiment just reselecting the dates that are already there when loaded.

Thanks! I installed the master branch and am also seeing an issue.
This is what I see on my super user (for which I changed the time zone to Europe/Berlin via the /admin page:

The "client time" is also off one hour:

I also created a new user with the correct time zone selected on creation and this is also somewhat off:

Thanks for the screenshots.

Well this is hilarious

class TimeZoneDateTimeField(serializers.DateTimeField):
    def to_native(self, value):
        value = timezone.localtime(value)
        return super(TimeZoneDateTimeField, self).to_native(value)

I put a breakpoint inside to_native and found that it was never being invoked at all. Never bothered vetting this snippet I took from a stack overflow.

(face hits desk)

Wrote a real TimeZoneDateTimeField serializer field and added a no-bullshit conversion to the queryset method. I'm more confident this is fixed. Try again.

I updated the installation, will see tomorrow how new records look like.

Hi Alex! I have tested it and it appears that part when page loads today's transactions - it works. It shows transaction which was added at something few seconds after midnight.

But what is weird is that when I change data range 16-Apr till 21-Arp, I get listed records with shown within that range and also few with date as "Apr 15, 2016". Is this because those records were created when bug was not yet fixed?

Thanks for checking that.

Is this because those records were created
when bug was not yet fixed?

That is probably true. Up until this point, my serializer field was
overriding the wrong function name, so who knows what has been happening
with dates. I would be interested to see what was saved, if you can
read right out of your database. I would recommend just recreating the records.