Daylight Savings Bug

[jamzfive]

When I was looking over my stats when I finished a session a little while ago, I surprised to see that PT had split my session into two sessions. I've seen it before, and it usually fixes if I export all the hands, purge the session, then re-load them. That solution didn't work any of the three times I tried it. So I looked a little closer to try to figure out when the problem had occurred. I soon noticed that the second session was made up of all the hands starting at 3 AM local time.

Then it hit me. The last hand of the "first" session occurred at 1:59 AM. Then the DST switch occurred and the clock moved forward an hour. The next hand took place at 3:00 AM. Taa-daa.

Is this something that warrants a look? I'd really like my one session to appear that way in the DB. I would imagine this same type of issue exists in PT3 as well (unless all times are stored in GST or something).

jb

[ptrack mike]

I don't know if this will be addressed in PT3, but if it really bothers you to have it split, export the two sessions that you want to be one. Then edit the timestamps on the hands around where DST occurred and make sure there is never more than 30 minutes between any two hands. Then re-import.

[jamzfive]

[quote="ptrack mike"c3y]I don't know if this will be addressed in PT3, but if it really bothers you to have it split, export the two sessions that you want to be one. Then edit the timestamps on the hands around where DST occurred and make sure there is never more than 30 minutes between any two hands. Then re-import.[/quotec3y]

OK, first of all, I must have been really tired last night, because I meant "GMT", not "GST" (whatever that is). And, if I'd been really awake, I'd have used "UTC" anyway. Now, onwards...

Your suggested solution was easy to do, since I only had about ten hands that needed to be changed. I now do only have one session; however, the session end time still says 3:03, instead of 2:03. I double-checked each of the hands in PT after re-importing, and I didn't miss any of them, and none of the histories have any timestamps other than the hand start time. Also interestingly, the session length was correct, this end time thing notwithstanding. What's going on here? I'm guessing that this isn't going to impact my calculated hourly rate or anything, since the session length ended up being correct?

I ran the following SQL in pgAdmin, and I was surprised at the result:
select max(session_end) from session;
> "2008-03-09 03:03:15-04"

It looks like the timezone is being stored in the database, and that something (the PT parser?, the database?) is smart enough to know that there was no "2008-03-09 02:03:15-05", and is accommodating for that? If this is so, I'm surprised that the 30 minute rule isn't able to work even with the DST change. All the pieces seem to be in place...


jb

Anyway, sorry for the rambling, but this interests me a bit. Can you tell I'm a s/w engineer by day?

[ptrack pat]

It's likely that PostgreSQL is accounting for this because PT doesn't change the dates that are being imported.