PMPARSETIMEWINDOW(3)

✨ PMPARSETIMEWINDOW(3) ✨

okay bestie, so this is a page from the Library Functions Manual and it's literally the whole lore on pmParseTimeWindow and pmParseHighResTimeWindow. Manual section 3, we love her 💅

---

🎀 NAME 🎀

pmParseTimeWindow, pmParseHighResTimeWindow — they parse time window command line arguments. that's it, that's the job 🫶

---

🌸 C SYNOPSIS 🌸

#include <pcp/pmapi.h>

int pmParseTimeWindow(const char *swStart, const char *swEnd,
        const char *swAlign, const char *swOffset,
        const struct timeval *logStart, const struct timeval *logEnd,
        struct timeval *rsltStart, struct timeval *rsltEnd,
        struct timeval *rsltOffset, char **errMsg);
int pmParseHighResTimeWindow(const char *swStart, const char *swEnd,
        const char *swAlign, const char *swOffset,
        const struct timespec *logStart, const struct timespec *logEnd,
        struct timespec *rsltStart, struct timespec *rsltEnd,
        struct timespec *rsltOffset, char **errMsg);

cc ... -lpcp

like yes you gotta link -lpcp, that's the vibe 💖

---

🦋 DESCRIPTION 🦋

so basically pmParseTimeWindow and pmParseHighResTimeWindow exist to encapsulate the interpretation of the -S, -T, -A and -O command line options that Performance Co-Pilot (PCP) applications use to define a time window of interest. main character energy fr fr 👑

the time window is defined by a start time and an end time that constrains the time interval during which the PCP application will retrieve and display performance metrics. and here's the tea: in the absence of the -O and -A options to specify an initial sample time origin and time alignment (see below), the PCP application will retrieve the first sample at the start of the time window. ✨

the syntax and meaning of the various argument formats for these options is described in PCPIntro(1). go read it, iykyk 📖

---

💅 USAGE 💅

pmParseTimeWindow and pmParseHighResTimeWindow expect to be called with the argument of the -S option as swStart, the argument of the -T option as swEnd, the argument of the -A option as swAlign, and the argument of the -O option as swOffset. any or all of these parameters may be NULL to indicate that the corresponding command line option was not present. no cap 🙈

if the application is using a set of PCP archives as the source of performance metrics, you also need to supply the time of the first archive entry as logStart, and the time of the last archive entry as logEnd. see pmGetArchiveLabel(3) and pmGetArchiveEnd(3) for how to obtain values for these times. 🎀

if the application is manipulating multiple concurrent archives, then the caller must resolve how the default time window is to be defined (the union of the time intervals in all archives is a likely interpretation). that's on you bestie 💀

if the application is using a live feed of performance data, logStart should be the current time (but could be aligned on the next second for example), while logEnd should have its tv_sec component set to PM_MAX_TIME_T. 🕐

the rsltStart, rsltEnd and rsltOffset structures must be allocated before calling pmParseTimeWindow or pmParseHighResTimeWindow. like, actually allocate them first, don't be out here with uninitialized pointers 😭

you also need to set the current PCP reporting time zone to correctly reflect the -z and -Z command line parameters before calling these routines. see pmUseZone(3) and friends for information on how this is done. 🌍

---

🔥 DIAGNOSTICS 🔥

• if the conversion is successful, pmParseTimeWindow and pmParseHighResTimeWindow return 1 and fill in rsltStart, rsltEnd and rsltOffset with the start, end, and offset times for the time window defined by the input parameters. the errMsg parameter is not changed when either pmParseTimeWindow or pmParseHighResTimeWindow returns 1. slay ✨
• if the conversion is successful, but the requested alignment could not be performed (e.g. the set of PCP archives is too short) the alignment is ignored, rsltStart, rsltEnd and rsltOffset are filled in and pmParseTimeWindow and pmParseHighResTimeWindow return 0. in this case, errMsg will point to a warning message in a dynamically allocated buffer. the caller is responsible for releasing the buffer by calling free(3). 👑
• if the argument strings could not be parsed, pmParseTimeWindow and pmParseHighResTimeWindow return -1. in this case, errMsg will point to an error message in a dynamically allocated buffer. the caller is responsible for releasing the buffer by calling free(3). 💀

⚠️ bestie listen: whenever errMsg points at a dynamically allocated buffer, YOU own that memory. free(3) it. don't leak, that's not the vibe 🫶

---

🌈 SEE ALSO 🌈

• free(3)
• PMAPI(3)
• pmGetArchiveEnd(3)
• pmGetArchiveLabel(3)
• pmNewContextZone(3)
• pmNewZone(3)
• pmParseInterval(3)
• pmUseZone(3)

---

and that's the whole page, bestie 💖 this one came out of Performance Co-Pilot (that's the PCP collective, the source, the moment) and it's filed under PMPARSETIMEWINDOW(3) — periodt. go parse some time windows, you're gonna ate 🎀✨