GH-30117: [C++][Python] Add "Z" to the end of timestamp print string when tz defined

[AlenkaF]

What changes are included in this PR?

This PR updates the PrettyPrint for Timestamp type so that "Z" is printed at the end of the output string if the timezone has been defined. This way we add minimum information about the values being stored in UTC.

Are these changes tested?

Yes.

Are there any user-facing changes?

There is a change in how TimestampArray prints out the data. With this change "Z" would be added to the end of the string if the timezone is defined.

• Closes: [C++][Python][R] PrettyPrint ignores timezone #30117

[github-actions]

⚠️ GitHub issue #30117has been automatically assigned in GitHub to PR creator.

[rok]

Seems good. Let's just check that weird zones don't cause issues.

[rok]

Forgot to ask: does this currently print timestamp's type when printing the array? And if it does can you add a test that it prints the correct timezone. If not we can leave it for the follow-up.

[AlenkaF]

Forgot to ask: does this currently print timestamp's type when printing the array? And if it does can you add a test that it prints the correct timezone. If not we can leave it for the follow-up.

No, when printing the array there is no info about the type, one should still inspect the type separately:

>>>importpyarrowaspa>>>a=pa.array([0], pa.timestamp('s', tz='+02:00'))
>>>a<pyarrow.lib.TimestampArrayobjectat0x131399fc0>
[
1970-01-0100:00:00Z
]
>>>a.typeTimestampType(timestamp[s, tz=+02:00])

as mentioned on the issue, we can add this if find important.

[rok]

as mentioned on the issue, we can add this if find important.

If there's an easy way to include timezone it would be great!

[jorisvandenbossche]

does this currently print timestamp's type when printing the array?

Given this is a completely separate code path (this is something defined in the python repr, not the C++ pretty printer), let's keep that for a separate PR?
(but yes, I agree it would be good to do that!)

[rok]

Given this is a completely separate code path (this is something defined in the python repr, not the C++ pretty printer), let's keep that for a separate PR? (but yes, I agree it would be good to do that!)

Agreed, let's make another issue for it.

[AlenkaF]

Given this is a completely separate code path (this is something defined in the python repr, not the C++ pretty printer), let's keep that for a separate PR? (but yes, I agree it would be good to do that!)

Agreed, let's make another issue for it.

It would be good to add that to R also, if I am not mistaken. Will create an issue for it 👍

[AlenkaF]

Opened an issue for printing timezone information in TimestampArray: #39315
cc @rok@jorisvandenbossche

[jorisvandenbossche]

Thanks!

[conbench-apache-arrow]

After merging your PR, Conbench analyzed the 6 benchmarking runs that have been run so far on merge-commit a288364.

There were no benchmark performance regressions. 🎉

The full Conbench report has more details. It also includes information about 4 possible false positives for unstable benchmarks that are known to sometimes produce them.

[AlenkaF]

What changes are included in this PR?

This PR updates the PrettyPrint for Timestamp type so that "Z" is printed at the end of the output string if the timezone has been defined. This way we add minimum information about the values being stored in UTC.

Are these changes tested?

Yes.

Are there any user-facing changes?

There is a change in how TimestampArray prints out the data. With this change "Z" would be added to the end of the string if the timezone is defined.

• Closes: [C++][Python][R] PrettyPrint ignores timezone #30117

[github-actions]

⚠️ GitHub issue #30117has been automatically assigned in GitHub to PR creator.

[rok]

Seems good. Let's just check that weird zones don't cause issues.

[rok]

Forgot to ask: does this currently print timestamp's type when printing the array? And if it does can you add a test that it prints the correct timezone. If not we can leave it for the follow-up.

[AlenkaF]

Forgot to ask: does this currently print timestamp's type when printing the array? And if it does can you add a test that it prints the correct timezone. If not we can leave it for the follow-up.

No, when printing the array there is no info about the type, one should still inspect the type separately:

>>>importpyarrowaspa>>>a=pa.array([0], pa.timestamp('s', tz='+02:00'))
>>>a<pyarrow.lib.TimestampArrayobjectat0x131399fc0>
[
1970-01-0100:00:00Z
]
>>>a.typeTimestampType(timestamp[s, tz=+02:00])

as mentioned on the issue, we can add this if find important.

[rok]

as mentioned on the issue, we can add this if find important.

If there's an easy way to include timezone it would be great!

[jorisvandenbossche]

does this currently print timestamp's type when printing the array?

Given this is a completely separate code path (this is something defined in the python repr, not the C++ pretty printer), let's keep that for a separate PR?
(but yes, I agree it would be good to do that!)

[rok]

Given this is a completely separate code path (this is something defined in the python repr, not the C++ pretty printer), let's keep that for a separate PR? (but yes, I agree it would be good to do that!)

Agreed, let's make another issue for it.

[AlenkaF]

Given this is a completely separate code path (this is something defined in the python repr, not the C++ pretty printer), let's keep that for a separate PR? (but yes, I agree it would be good to do that!)

Agreed, let's make another issue for it.

It would be good to add that to R also, if I am not mistaken. Will create an issue for it 👍

[AlenkaF]

Opened an issue for printing timezone information in TimestampArray: #39315
cc @rok@jorisvandenbossche

[jorisvandenbossche]

Thanks!

[conbench-apache-arrow]

After merging your PR, Conbench analyzed the 6 benchmarking runs that have been run so far on merge-commit a288364.

There were no benchmark performance regressions. 🎉

The full Conbench report has more details. It also includes information about 4 possible false positives for unstable benchmarks that are known to sometimes produce them.

[AlenkaF]

What changes are included in this PR?

This PR updates the PrettyPrint for Timestamp type so that "Z" is printed at the end of the output string if the timezone has been defined. This way we add minimum information about the values being stored in UTC.

Are these changes tested?

Yes.

Are there any user-facing changes?

There is a change in how TimestampArray prints out the data. With this change "Z" would be added to the end of the string if the timezone is defined.

• Closes: [C++][Python][R] PrettyPrint ignores timezone #30117

[github-actions]

⚠️ GitHub issue #30117has been automatically assigned in GitHub to PR creator.

[rok]

Seems good. Let's just check that weird zones don't cause issues.

[rok]

Forgot to ask: does this currently print timestamp's type when printing the array? And if it does can you add a test that it prints the correct timezone. If not we can leave it for the follow-up.

[AlenkaF]

Forgot to ask: does this currently print timestamp's type when printing the array? And if it does can you add a test that it prints the correct timezone. If not we can leave it for the follow-up.

No, when printing the array there is no info about the type, one should still inspect the type separately:

>>>importpyarrowaspa>>>a=pa.array([0], pa.timestamp('s', tz='+02:00'))
>>>a<pyarrow.lib.TimestampArrayobjectat0x131399fc0>
[
1970-01-0100:00:00Z
]
>>>a.typeTimestampType(timestamp[s, tz=+02:00])

as mentioned on the issue, we can add this if find important.

[rok]

as mentioned on the issue, we can add this if find important.

If there's an easy way to include timezone it would be great!

[jorisvandenbossche]

does this currently print timestamp's type when printing the array?

Given this is a completely separate code path (this is something defined in the python repr, not the C++ pretty printer), let's keep that for a separate PR?
(but yes, I agree it would be good to do that!)

[rok]

Given this is a completely separate code path (this is something defined in the python repr, not the C++ pretty printer), let's keep that for a separate PR? (but yes, I agree it would be good to do that!)

Agreed, let's make another issue for it.

[AlenkaF]

Given this is a completely separate code path (this is something defined in the python repr, not the C++ pretty printer), let's keep that for a separate PR? (but yes, I agree it would be good to do that!)

Agreed, let's make another issue for it.

It would be good to add that to R also, if I am not mistaken. Will create an issue for it 👍

[AlenkaF]

Opened an issue for printing timezone information in TimestampArray: #39315
cc @rok@jorisvandenbossche

[jorisvandenbossche]

Thanks!

[conbench-apache-arrow]

After merging your PR, Conbench analyzed the 6 benchmarking runs that have been run so far on merge-commit a288364.

There were no benchmark performance regressions. 🎉

The full Conbench report has more details. It also includes information about 4 possible false positives for unstable benchmarks that are known to sometimes produce them.

[AlenkaF]

What changes are included in this PR?

This PR updates the PrettyPrint for Timestamp type so that "Z" is printed at the end of the output string if the timezone has been defined. This way we add minimum information about the values being stored in UTC.

Are these changes tested?

Yes.

Are there any user-facing changes?

There is a change in how TimestampArray prints out the data. With this change "Z" would be added to the end of the string if the timezone is defined.

• Closes: [C++][Python][R] PrettyPrint ignores timezone #30117

[github-actions]

⚠️ GitHub issue #30117has been automatically assigned in GitHub to PR creator.

[rok]

Seems good. Let's just check that weird zones don't cause issues.

[rok]

Forgot to ask: does this currently print timestamp's type when printing the array? And if it does can you add a test that it prints the correct timezone. If not we can leave it for the follow-up.

[AlenkaF]

Forgot to ask: does this currently print timestamp's type when printing the array? And if it does can you add a test that it prints the correct timezone. If not we can leave it for the follow-up.

No, when printing the array there is no info about the type, one should still inspect the type separately:

>>>importpyarrowaspa>>>a=pa.array([0], pa.timestamp('s', tz='+02:00'))
>>>a<pyarrow.lib.TimestampArrayobjectat0x131399fc0>
[
1970-01-0100:00:00Z
]
>>>a.typeTimestampType(timestamp[s, tz=+02:00])

as mentioned on the issue, we can add this if find important.

[rok]

as mentioned on the issue, we can add this if find important.

If there's an easy way to include timezone it would be great!

[jorisvandenbossche]

does this currently print timestamp's type when printing the array?

Given this is a completely separate code path (this is something defined in the python repr, not the C++ pretty printer), let's keep that for a separate PR?
(but yes, I agree it would be good to do that!)

[rok]

Given this is a completely separate code path (this is something defined in the python repr, not the C++ pretty printer), let's keep that for a separate PR? (but yes, I agree it would be good to do that!)

Agreed, let's make another issue for it.

[AlenkaF]

Given this is a completely separate code path (this is something defined in the python repr, not the C++ pretty printer), let's keep that for a separate PR? (but yes, I agree it would be good to do that!)

Agreed, let's make another issue for it.

It would be good to add that to R also, if I am not mistaken. Will create an issue for it 👍

[AlenkaF]

Opened an issue for printing timezone information in TimestampArray: #39315
cc @rok@jorisvandenbossche

[jorisvandenbossche]

Thanks!

[conbench-apache-arrow]

After merging your PR, Conbench analyzed the 6 benchmarking runs that have been run so far on merge-commit a288364.

There were no benchmark performance regressions. 🎉

The full Conbench report has more details. It also includes information about 4 possible false positives for unstable benchmarks that are known to sometimes produce them.

[AlenkaF]

What changes are included in this PR?

This PR updates the PrettyPrint for Timestamp type so that "Z" is printed at the end of the output string if the timezone has been defined. This way we add minimum information about the values being stored in UTC.

Are these changes tested?

Yes.

Are there any user-facing changes?

There is a change in how TimestampArray prints out the data. With this change "Z" would be added to the end of the string if the timezone is defined.

• Closes: [C++][Python][R] PrettyPrint ignores timezone #30117

[github-actions]

⚠️ GitHub issue #30117has been automatically assigned in GitHub to PR creator.

[rok]

Seems good. Let's just check that weird zones don't cause issues.

[rok]

Forgot to ask: does this currently print timestamp's type when printing the array? And if it does can you add a test that it prints the correct timezone. If not we can leave it for the follow-up.

[AlenkaF]

Forgot to ask: does this currently print timestamp's type when printing the array? And if it does can you add a test that it prints the correct timezone. If not we can leave it for the follow-up.

No, when printing the array there is no info about the type, one should still inspect the type separately:

>>>importpyarrowaspa>>>a=pa.array([0], pa.timestamp('s', tz='+02:00'))
>>>a<pyarrow.lib.TimestampArrayobjectat0x131399fc0>
[
1970-01-0100:00:00Z
]
>>>a.typeTimestampType(timestamp[s, tz=+02:00])

as mentioned on the issue, we can add this if find important.

[rok]

as mentioned on the issue, we can add this if find important.

If there's an easy way to include timezone it would be great!

[jorisvandenbossche]

does this currently print timestamp's type when printing the array?

Given this is a completely separate code path (this is something defined in the python repr, not the C++ pretty printer), let's keep that for a separate PR?
(but yes, I agree it would be good to do that!)

[rok]

Given this is a completely separate code path (this is something defined in the python repr, not the C++ pretty printer), let's keep that for a separate PR? (but yes, I agree it would be good to do that!)

Agreed, let's make another issue for it.

[AlenkaF]

Given this is a completely separate code path (this is something defined in the python repr, not the C++ pretty printer), let's keep that for a separate PR? (but yes, I agree it would be good to do that!)

Agreed, let's make another issue for it.

It would be good to add that to R also, if I am not mistaken. Will create an issue for it 👍

[AlenkaF]

Opened an issue for printing timezone information in TimestampArray: #39315
cc @rok@jorisvandenbossche

[jorisvandenbossche]

Thanks!

[conbench-apache-arrow]

After merging your PR, Conbench analyzed the 6 benchmarking runs that have been run so far on merge-commit a288364.

There were no benchmark performance regressions. 🎉

The full Conbench report has more details. It also includes information about 4 possible false positives for unstable benchmarks that are known to sometimes produce them.

[AlenkaF]

What changes are included in this PR?

This PR updates the PrettyPrint for Timestamp type so that "Z" is printed at the end of the output string if the timezone has been defined. This way we add minimum information about the values being stored in UTC.

Are these changes tested?

Yes.

Are there any user-facing changes?

There is a change in how TimestampArray prints out the data. With this change "Z" would be added to the end of the string if the timezone is defined.

• Closes: [C++][Python][R] PrettyPrint ignores timezone #30117

[github-actions]

⚠️ GitHub issue #30117has been automatically assigned in GitHub to PR creator.

[rok]

Seems good. Let's just check that weird zones don't cause issues.

[rok]

Forgot to ask: does this currently print timestamp's type when printing the array? And if it does can you add a test that it prints the correct timezone. If not we can leave it for the follow-up.

[AlenkaF]

Forgot to ask: does this currently print timestamp's type when printing the array? And if it does can you add a test that it prints the correct timezone. If not we can leave it for the follow-up.

No, when printing the array there is no info about the type, one should still inspect the type separately:

>>>importpyarrowaspa>>>a=pa.array([0], pa.timestamp('s', tz='+02:00'))
>>>a<pyarrow.lib.TimestampArrayobjectat0x131399fc0>
[
1970-01-0100:00:00Z
]
>>>a.typeTimestampType(timestamp[s, tz=+02:00])

as mentioned on the issue, we can add this if find important.

[rok]

as mentioned on the issue, we can add this if find important.

If there's an easy way to include timezone it would be great!

[jorisvandenbossche]

does this currently print timestamp's type when printing the array?

Given this is a completely separate code path (this is something defined in the python repr, not the C++ pretty printer), let's keep that for a separate PR?
(but yes, I agree it would be good to do that!)

[rok]

Given this is a completely separate code path (this is something defined in the python repr, not the C++ pretty printer), let's keep that for a separate PR? (but yes, I agree it would be good to do that!)

Agreed, let's make another issue for it.

[AlenkaF]

Given this is a completely separate code path (this is something defined in the python repr, not the C++ pretty printer), let's keep that for a separate PR? (but yes, I agree it would be good to do that!)

Agreed, let's make another issue for it.

It would be good to add that to R also, if I am not mistaken. Will create an issue for it 👍

[AlenkaF]

Opened an issue for printing timezone information in TimestampArray: #39315
cc @rok@jorisvandenbossche

[jorisvandenbossche]

Thanks!

[conbench-apache-arrow]

After merging your PR, Conbench analyzed the 6 benchmarking runs that have been run so far on merge-commit a288364.

There were no benchmark performance regressions. 🎉

The full Conbench report has more details. It also includes information about 4 possible false positives for unstable benchmarks that are known to sometimes produce them.

[AlenkaF]

What changes are included in this PR?

This PR updates the PrettyPrint for Timestamp type so that "Z" is printed at the end of the output string if the timezone has been defined. This way we add minimum information about the values being stored in UTC.

Are these changes tested?

Yes.

Are there any user-facing changes?

There is a change in how TimestampArray prints out the data. With this change "Z" would be added to the end of the string if the timezone is defined.

• Closes: [C++][Python][R] PrettyPrint ignores timezone #30117

[github-actions]

⚠️ GitHub issue #30117has been automatically assigned in GitHub to PR creator.

[rok]

Seems good. Let's just check that weird zones don't cause issues.

[rok]

Forgot to ask: does this currently print timestamp's type when printing the array? And if it does can you add a test that it prints the correct timezone. If not we can leave it for the follow-up.

[AlenkaF]

Forgot to ask: does this currently print timestamp's type when printing the array? And if it does can you add a test that it prints the correct timezone. If not we can leave it for the follow-up.

No, when printing the array there is no info about the type, one should still inspect the type separately:

>>>importpyarrowaspa>>>a=pa.array([0], pa.timestamp('s', tz='+02:00'))
>>>a<pyarrow.lib.TimestampArrayobjectat0x131399fc0>
[
1970-01-0100:00:00Z
]
>>>a.typeTimestampType(timestamp[s, tz=+02:00])

as mentioned on the issue, we can add this if find important.

[rok]

as mentioned on the issue, we can add this if find important.

If there's an easy way to include timezone it would be great!

[jorisvandenbossche]

does this currently print timestamp's type when printing the array?

Given this is a completely separate code path (this is something defined in the python repr, not the C++ pretty printer), let's keep that for a separate PR?
(but yes, I agree it would be good to do that!)

[rok]

Given this is a completely separate code path (this is something defined in the python repr, not the C++ pretty printer), let's keep that for a separate PR? (but yes, I agree it would be good to do that!)

Agreed, let's make another issue for it.

[AlenkaF]

Given this is a completely separate code path (this is something defined in the python repr, not the C++ pretty printer), let's keep that for a separate PR? (but yes, I agree it would be good to do that!)

Agreed, let's make another issue for it.

It would be good to add that to R also, if I am not mistaken. Will create an issue for it 👍

[AlenkaF]

Opened an issue for printing timezone information in TimestampArray: #39315
cc @rok@jorisvandenbossche

[jorisvandenbossche]

Thanks!

[conbench-apache-arrow]

After merging your PR, Conbench analyzed the 6 benchmarking runs that have been run so far on merge-commit a288364.

There were no benchmark performance regressions. 🎉

The full Conbench report has more details. It also includes information about 4 possible false positives for unstable benchmarks that are known to sometimes produce them.

[AlenkaF]

What changes are included in this PR?

This PR updates the PrettyPrint for Timestamp type so that "Z" is printed at the end of the output string if the timezone has been defined. This way we add minimum information about the values being stored in UTC.

Are these changes tested?

Yes.

Are there any user-facing changes?

There is a change in how TimestampArray prints out the data. With this change "Z" would be added to the end of the string if the timezone is defined.

• Closes: [C++][Python][R] PrettyPrint ignores timezone #30117

[github-actions]

⚠️ GitHub issue #30117has been automatically assigned in GitHub to PR creator.

[rok]

Seems good. Let's just check that weird zones don't cause issues.

[rok]

Forgot to ask: does this currently print timestamp's type when printing the array? And if it does can you add a test that it prints the correct timezone. If not we can leave it for the follow-up.

[AlenkaF]

Forgot to ask: does this currently print timestamp's type when printing the array? And if it does can you add a test that it prints the correct timezone. If not we can leave it for the follow-up.

No, when printing the array there is no info about the type, one should still inspect the type separately:

>>>importpyarrowaspa>>>a=pa.array([0], pa.timestamp('s', tz='+02:00'))
>>>a<pyarrow.lib.TimestampArrayobjectat0x131399fc0>
[
1970-01-0100:00:00Z
]
>>>a.typeTimestampType(timestamp[s, tz=+02:00])

as mentioned on the issue, we can add this if find important.

[rok]

as mentioned on the issue, we can add this if find important.

If there's an easy way to include timezone it would be great!

[jorisvandenbossche]

does this currently print timestamp's type when printing the array?

Given this is a completely separate code path (this is something defined in the python repr, not the C++ pretty printer), let's keep that for a separate PR?
(but yes, I agree it would be good to do that!)

[rok]

Given this is a completely separate code path (this is something defined in the python repr, not the C++ pretty printer), let's keep that for a separate PR? (but yes, I agree it would be good to do that!)

Agreed, let's make another issue for it.

[AlenkaF]

Given this is a completely separate code path (this is something defined in the python repr, not the C++ pretty printer), let's keep that for a separate PR? (but yes, I agree it would be good to do that!)

Agreed, let's make another issue for it.

It would be good to add that to R also, if I am not mistaken. Will create an issue for it 👍

[AlenkaF]

Opened an issue for printing timezone information in TimestampArray: #39315
cc @rok@jorisvandenbossche

[jorisvandenbossche]

Thanks!

[conbench-apache-arrow]

After merging your PR, Conbench analyzed the 6 benchmarking runs that have been run so far on merge-commit a288364.

There were no benchmark performance regressions. 🎉

The full Conbench report has more details. It also includes information about 4 possible false positives for unstable benchmarks that are known to sometimes produce them.