#1002 promised to fix #403 and has been merged to master. As I discovered now it is only a partial fix.

Recall the issue was the dateparser would skip ahead a day if the time had already passed in UTC when preferring dates from the future. For example parsing 6pm EST (11pm UTC) at 10pm UTC would return tomorrow 11pm, instead of today 11pm UTC.

#1002 addresses this by passing the time zone so the correct relative base can be computed. What I didn't realize at the time is that ptz is only the time zone popped off the string. So, if the timezone is supplied via settings instead, nothing is passed along and the old bug from #403 reappears.

I might submit a pull request in the future but I wanted to report it already.

Versions:

• Ubuntu 22.04.1 LTS
• Python 3.10.6
• dateparser (1.1.3)
  • python-dateutil (2.8.2)
  • pytz (2022.6)
  • regex (2022.3.2)
  • tzlocal (4.2)

Minimum working example:

import dateparser
import datetime

working_settings={
        'PREFER_DATES_FROM': 'future',
        'TO_TIMEZONE': 'etc/utc',
        'RETURN_AS_TIMEZONE_AWARE': False,
        'RELATIVE_BASE': datetime.datetime(2022, 11, 6, 22, 0)
        }

broken_settings = working_settings
broken_settings['TIMEZONE'] = 'america/new_york'

correct_time = dateparser.parse('6pm EST', settings=working_settings)
print(correct_time) # 2022-11-06 23:00:00

wrong_time = dateparser.parse('6pm', settings=broken_settings)
print(wrong_time) # 2022-11-07 23:00:00