To clarify, my local client timezone and timezone of all things in the browser and Personio is:

$ date --iso-8601=seconds
2023-01-12T16:13:21+01:00

(I ran this directly after making and annotating the screenshot.)

Hey @Zejo 

Welcome to the Personio Community 

Our API transfers data in the UTC (Coordinated Universal Time). This also applies to the calendar integration for calendar entries just to let you know. I would kindly ask that you convert the time information to match the time zone you are in. 

I am happy to assist you in any other issues you may be having.

Best,

Conor

The “...+01:00” that your API timestamps contain is supposed to mean that the preceding date-time refers to a point in time in a time-zone offset by 1h from UTC.

You may also refer to the following norms/industry standards:

ISO8601 https://en.wikipedia.org/wiki/ISO_8601#Time_offsets_from_UTC

RFC 3339 https://www.rfc-editor.org/rfc/rfc3339#section-4.2

It may be hard to correct this mistake globally at this point, but there should really be a way forward. We are waiting for APIv2.

@ConorCunningham I may not have emphasized this point enough, the absence created_at and updated_at timestamps are unreliable (wrong datetime, shifted by one hour at least) if one creates an event manually in the Personio UI (Absence Calendar).

Creating an event via API leads to a correct timestamp.

To illustrate, both of the following events were created a few minutes apart, the first one manually in the browser (wrong timestamps, the current time in the Berlin/Paris TZ is 16:30), the second one via API (correct timestamps):

[
    {
      "type": "TimeOffPeriod",
      "attributes": {
        "id": 175968804,
        "status": "approved",
        "comment": "Test Test",
        "start_date": "2023-01-06T00:00:00+01:00",
        "end_date": "2023-01-06T00:00:00+01:00",
        "days_count": 0,
        "half_day_start": 0,
        "half_day_end": 0,
        "time_off_type": {
          "type": "TimeOffType",
          "attributes": {
            "id": 184018,
            "name": "Parental leave",
            "category": "parental_leave"
          }
        },

        "created_by": "Jonas Zeiger",
        "certificate": {
          "status": "not-required"
        },
        "created_at": "2023-01-16T17:09:14+01:00",
        "updated_at": "2023-01-16T17:09:14+01:00"
      }
    },
    {
      "type": "TimeOffPeriod",
      "attributes": {
        "id": 175969523,
        "status": "approved",
        "comment": "vacation: test 123",
        "start_date": "2023-01-09T00:00:00+01:00",
        "end_date": "2023-01-09T00:00:00+01:00",
        "days_count": 0.5,
        "half_day_start": 0,
        "half_day_end": 1,
        "time_off_type": {
          "type": "TimeOffType",
          "attributes": {
            "id": 155627,
            "name": "Vacation",
            "category": "paid_vacation"
          }
        },

        "created_by": "API",
        "certificate": {
          "status": "not-required"
        },
        "created_at": "2023-01-16T16:14:44+01:00",
        "updated_at": "2023-01-16T16:14:44+01:00"
      }
    }
]

Please have somebody from engineering have a look at this.

Hey @Zejo 
 

Thank you for providing this information.

As this will need to be investigated by a member of our Technical team, I would kindly ask that you submit this issue via our Find Answers section through a support request.

This will allow us to investigate this more thoroughly and see if a solution can be found.

We look forward to receiving your request.

Best,

Conor

I tested this issue in a browser with TZ=America/New_York set and the timestamp shift seems to be independent from the local timezone (at least).

So you either fix this issue or I have to add a special workaround to my code handling updated_at that follows this pseudo-code:

// This will only work reliably if the time between calling this function
// and the update, leading to the "updated_at" being set, are at most 1h apart.
function getUpdatedAtWorkaround(timeOff) {
    const updatedAt = new Date(timeOff.attributes.updated_at);
    if (timeOff.attributes.created_by !== 'API' || +updatedAt >= Date.now()) {
        updatedAt.setTime(updatedAt.getTime() + (-1 * 60 * 60 * 1000)); // -1h
    }
    return updatedAt; 
}

Dear @Zejo,

Thank you for your response.

As my colleague Conor stated, we would kindly ask you to contact our support team for this topic. My colleagues will be able to log in into your account and check the settings together with you.

Be aware that only Contract and Account owners can contact our support team. In case you are not registered as such, please contact your colleagues in the role, or add this information. You can find out how here.

Please let me know if there is anything else we can support you with.

I wish you a lovely start in to the week.

Best,

Andrea

@Zejo did you receive an adequate solution or are you still using your work around? We are having issues with the entries from the future.

@James According to Personio there are larger changes in progress and this issue thus wasn’t prioritized. We also need this fixed at some point.