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

feat: and start_nanos, end_nanos, timezone to PdlBlock model #285

Merged
merged 1 commit into from
Jan 22, 2025

Conversation

starpit
Copy link
Member

@starpit starpit commented Jan 21, 2025

Also updates the react UI to display this information.

pdl-viewer-react-v12

@starpit starpit requested a review from mandel January 21, 2025 18:37
@starpit starpit force-pushed the timing branch 6 times, most recently from 1dfe5b8 to 5601785 Compare January 22, 2025 01:45
Copy link
Collaborator

@mandel mandel left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This PR is great. The comments are minor and optional.

"""
timezone: Optional[str] = ""
"""Timezone of start_nanos and end_nanos
"""
# Fields for internal use
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would move the new fields under this comment.

Comment on lines +87 to +94
now = datetime.datetime.now()
local_now = now.astimezone()
local_tz = local_now.tzinfo
if local_tz is not None:
local_tzname = local_tz.tzname(local_now)
else:
local_tzname = "UTC"
d["timezone"] = local_tzname
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What about computing the time zone once and setting it up in the interpreter in the step_advanced_block_timed function?

Copy link
Member Author

@starpit starpit Jan 22, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i'm not sure if there is a great solution to this. either we do it outside of block_to_dict(), but then we would either need to pass this value in as a parameter, or we would need to store the timezone as a global variable. by design, it seems that the trace format does not allow for a global wrapper, where we could compute and store the timezone (and any other trace metadata, e.g. who created it, when it was created, etc.).

an alternate solution would be to store the start and end timestamps as formatted timestamps (this is how kubernetes does it), so that the timezone is encoded into each timestamp. but then we are formatting timestamps all the time... is this less expensive than computing the timezone? dunno.

in any case, i propose that this is premature optimization. computing the timezone once per non-scalar block seems like a minor expense compared to the cost of serializing the block.

also, i intentionally placed the timezone code in the dumper, to pull it out of the path of the normal interpretation. i.e. this extra expense is only occurred when running in --trace mode.

Also updates the react UI to display this information.

Signed-off-by: Nick Mitchell <[email protected]>
@starpit starpit merged commit 1b7ff82 into IBM:main Jan 22, 2025
6 checks passed
@starpit starpit deleted the timing branch January 22, 2025 19:16
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