Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Preserve The Specified Timezone In Parse #633

Merged
merged 2 commits into from
Apr 24, 2024

Conversation

cwarden
Copy link
Contributor

@cwarden cwarden commented Apr 23, 2024

When parsing a string into a Time using the optional timezone parameter, set the location of the Time to the timezone's location so that Format uses that timezone.

When parsing a string into a Time using the optional timezone
parameter, set the location of the Time to the timezone's location so
that Format uses that timezone.
cwarden added a commit to octoberswimmer/batchforce that referenced this pull request Apr 23, 2024
When parsing a string into a Time using the optional timezone
parameter to `date`, set the location of the Time to the timezone's
location so that Format uses that timezone.

See expr-lang/expr#633
cwarden added a commit to octoberswimmer/batchforce that referenced this pull request Apr 23, 2024
When parsing a string into a Time using the optional timezone
parameter to `date`, set the location of the Time to the timezone's
location so that Format uses that timezone.

See expr-lang/expr#633
@antonmedv
Copy link
Member

Let's add mode tests for this use case?

Add test when timezone is used to parse a date-time.

Add test when timezone is irrelevant because it's a date.
@cwarden
Copy link
Contributor Author

cwarden commented Apr 23, 2024

Let's add mode tests for this use case?

I added a couple more in 42ff6c6. Can you think of other use cases that need to be covered?

@cwarden cwarden mentioned this pull request Apr 24, 2024
@antonmedv antonmedv merged commit e6dfb71 into expr-lang:master Apr 24, 2024
10 checks passed
@antonmedv
Copy link
Member

I think we not need this PR any more.

Here is the logic:

If parsed date has a TZ data +0100, ParseInLocation uses it.

date("2023-04-23T00:30:00.000+0100", "2006-01-02T15:04:05-0700", "America/Chicago")
2023-04-23 00:30:00 +0100 +0100

Without TZ data, third param is used as TZ:

date("2023-04-23T00:30:00.000", "2006-01-02T15:04:05", "America/Chicago")
2023-04-23 00:30:00 -0500 CDT

So we do not need implicit convert with In any more.

@antonmedv
Copy link
Member

date("2023-04-23T00:30:00.000", "2006-01-02T15:04:05", "America/Chicago")
2023-04-23 00:30:00 -0500 CDTdate("2023-04-23T00:30:00.000", "2006-01-02T15:04:05", "America/Chicago").In(timezone("America/Chicago"))
2023-04-23 00:30:00 -0500 CDT

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants