Strange issue with inconsistent behavior

[zefoo]

I do this:

cal = parsedatetime.Calendar() datetime_obj, parse_status = cal.parseDT(datetimeString='thursday 6:00 am', tzinfo=timezone('Europe/Bucharest'))

Resulting time I get is this:

2016-06-30 03:00:00+00:00

Here's the problem: I get this result when I run the query at 6:40am on June 30th.

I think what's happening is because it's pre 9am (or some other time), it returns a time that has already passed instead of the following Thursday. eg. I was expecting this: 2016-07-07 03:00:00+00:00

I don't see this in the docs, but will do more testing. Any input appreciated on why this happens. I'm expecting to say "Thursday 6:00am" and if the current time in given timezone is past 6am, return the following Thursday. I'm not seeing this behavior, though.

Thank you -

[bear]

there should be a flag you can set in PDT that controls whether to use current, prior or next week when evaluating those types of expressions -- I'm on the road and don't have full access to my desktop so I'm having trouble finding it

I'll check back later when I'm at my desk

[zefoo]

Thank you, I couldn't seem to find that either – maybe I'm not looking in the right place. Being able to say, "Thursday 6am" (On a Thursday at 6:42am) and force it to return the following Thursday would indeed solve my issue. Thanks Bear.

[bear]

k, found it - if you look at https://github.com/bear/parsedatetime/blob/master/parsedatetime/__init__.py#L2314

you will find quite a few constants that control how the system handles filling in missing information along with comments that describe the behaviour

[zefoo]

Thank you Bear. I read through the examples, and your link, and have tried multiple variations (each time thinking, "I got it this time."), but I'm not able to get the results I'm after.

I'm using this:

c = parsedatetime.Constants(); 
c.StartTimeFromSourceTime=True; 
c.DOWParseStyle=+1; 
c.CurrentDOWParseStyle=False; 
cal = parsedatetime.Calendar(c); 
date, status=cal.parseDT(datetimeString='Thursday 2am', tzinfo=timezone('Asia/Manila')); 
print(date, status)

Current time in Asia/Manila is (as I ran this): 4:14 AM Thursday, July 7, 2016 (GMT+8)

Result: 2016-07-07 02:00:00+08:00 3

My expectation: Since the current time in Asia/Manila is Thursday 4:14am, and I asked for Thursday 2am (and I set starting source time and other constants as I understand them to get the result I want), I'm expecting this result:

2016-07-14 02:00:00+08:00 3 (core difference, next Thursday, 2am, not 2am in the past)

Can you enlighten me? Am I missing something obvious? Thank you. :)

[bear]

hmm, that is odd for sure -- I won't be able to look at it until this weekend but I sure will

[zefoo]

Thanks Mike, I'm baffled. It seems like it should work properly if I'm understanding the docs correctly.

[zefoo]

If anyone else has this issue, I'll set up a workaround to add the word "next Thursday" in my code if the time in given timezone is pre-9am. I think that'll be a good workaround in the meantime since I think that's the core of my issue.

[zefoo]

Hey Mike, happen to have any idea on this? I appreciate any time you're willing to spend. My "next Thursday" temp. fix still operates differently and sometimes unexpected since the constants don't appear to be working properly. (Unless I'm missing something here) Thank you.

[bear]

@zefoo apologies for the delay in responding, I was AFK from the internet for the last week and i'm just now catching up

[zefoo]

Sounds like a good time. :) Thanks for the heads up! I'm really curious what you find.

[zefoo]

Hey Mike, any updates on this by any chance? I still can't seem to figure this out for the life of me. Thank you so much, appreciate any time you're willing to spend narrowing this down.

[zefoo]

I believe the issue here was because I wasn't passing sourceTime arg when processing. I don't believe I've seen this issue again since I made that change.