- Notifications
You must be signed in to change notification settings - Fork1k
Open
Labels
Description
🚀 Feature Request
when parsing a javascriptDate object to a pythondatetime object, playwright correctly parses the string with the UTC timezone, since that's how js dates are are stored internally:
playwright-python/playwright/_impl/_js_handle.py
Lines 243 to 247 in445f80a
| # Node.js Date objects are always in UTC. | |
| returndatetime.datetime.strptime( | |
| value["d"],"%Y-%m-%dT%H:%M:%S.%fZ" | |
| ).replace(tzinfo=datetime.timezone.utc) | |
however they do not get converted back to the browser context's timezone, which can be a source of bugs when working withdatetimes in python, for example:
fromdatetimeimportdatetimefromplaywright.sync_apiimportsync_playwrightwithsync_playwright()aspw:page= (pw.chromium.launch(headless=False) .new_context(timezone_id="Australia/Sydney") .new_page() )# imagine we're getting a date from something on the page that we then need to then input into a date field,# in this case we get January 1 2020date:datetime=page.evaluate("() => new Date(2020,0,1)")# we assume the timezone is correct, because the browser is configured to use that timezone, but once we try# to use the value, it's wrong (December 31 2019)page.locator("input").fill(date.strftime("%d/%m/%Y"))
i think the solution is for playwright to convert thedatetime object to the browser context's timezone once it's already been parsed using UTC, so something like this:
if "d" in value: # Node.js Date objects are always in UTC. return datetime.datetime.strptime( value["d"], "%Y-%m-%dT%H:%M:%S.%fZ"- ).replace(tzinfo=datetime.timezone.utc)+ ).replace(tzinfo=datetime.timezone.utc).astimezone(context.timezone)
Example
No response
Motivation
this will make it less likely for users to accidentally introduce timezone-related bugs in their code.