A user is getting a 500 error, related to his dataset and usage (our examples work fine). He can share limited information about his data due to confidentiality, but maybe someone has some advice on what he might change? @Marco @Yibei @Mariana Menchero. Thanks so much for ideas!

We get it from the input times, e.g.

tz = df[time_col].<http://dt.tz|dt.tz>

, if that's not

None

then it'll have a timezone object

ok, that's what I used.

I think it makes a lot of sense to just implement this in the SDK, at least in the ideal world. However, in terms of usability and current customer support process, I think it could be more convenient to include the UTC support directly in the current API version (as well as in the V2.). For context, @José Morales and others, we have found ourselves often involved in the following process: 1. A user finds an error 500 and sends email or slack message. 2. Sometimes they include the error body and we get the error id. Sometimes they include data they are sending. Sometimes they don't include anything and @Tracy Teal has to ask for more info. 3. If they provide data someone might notice that the timestamp is weird and suggest to either trimm the last part of the date or install the new SDK. If they don't, someone has to go look and find the payload using the error id. For the moment, just @azul (she/her) (nixtla) and you know how to do it. (We are working in giving more people access to be able to debug in that same manner.) 4. After either you or @azul (she/her) (nixtla) finds that the problem is the date and communicated it to @Tracy Teal, she would need to write them and ask them to trim the date or install the new version of the SDK. If we natively supported the UTC Datestamps in the API we would spare us that back and forth and many users of the current version of the SDK will have a better experience. Of course, I'm assuming here that the implementation in the API is not that complicated and could save many people (user, tracy, jose or azul) some work for this problem. Wdyt?

Hi, here are my thoughts: - Today, Capi helped me improve the implementation in my PR for UTC support. - I decided to work on this problem a few days ago for two reasons: firstly, because I was also dealing with dates in nixtlar, and secondly, I had spent a lot of time reviewing the Python code and thought the solution was relatively straightforward (and it is, there are just a few lines of code). I saw the issue and decided to give it a go, but maybe I shouldn't have address it just yet? - I also don't know how complicated the support is directly in the API. If it is not too complicated, then probably we should address it there. - Maybe we can use this as an opportunity to better define which tasks should be handled by the API and which by the SDKs, especially considering that significant changes are being implemented in both SDKs.

There's no need to do all that manual work, we have the stacktraces here, the timezone error is most likely this:

File "/root/api/utils/models.py", line 52, in fit
    design_matrix_df = Y_df.merge(X_df, how="left", on=self.id_cols)
  File "/usr/local/lib/python3.10/site-packages/pandas/core/frame.py", line 10832, in merge
    return merge(
  File "/usr/local/lib/python3.10/site-packages/pandas/core/reshape/merge.py", line 170, in merge
    op = _MergeOperation(
  File "/usr/local/lib/python3.10/site-packages/pandas/core/reshape/merge.py", line 807, in __init__
    self._maybe_coerce_merge_keys()
  File "/usr/local/lib/python3.10/site-packages/pandas/core/reshape/merge.py", line 1522, in _maybe_coerce_merge_keys
    raise ValueError(msg)
ValueError: You are trying to merge on datetime64[ns] and datetime64[ns, UTC] columns for key 'ds'. If you wish to proceed you should use pd.concat

Thanks for the PR.

There's no need to do all that manual work, we have the stacktraces here, the timezone error is most likely this:

Those are the modal errors rigth? Quick question: do those stacktraces have a

requestID": "PK6SQAQTAW

field so either Tracy or someone else can match the reported error with the trace?

@kevin and I talked about this. Having the request ID doesn't give us more information to look into anything. But even if it does, a user doesn't always supply it, so I often have to ask, so there are still those same set of back and forth steps.

I don't think we get the request id in modal, that's assigned in the middleware. What you could do is lookup the latest requests from the user and match the timestamps of the errors

the api with the fix by @José Morales is now deployed, this should fix the utc errors without updating the sdk 🫶 @Tracy Teal perhaps we could let the users know thank you all! 💙

It works in the sense that it doesn't raise an error, however it returns the timestamps without timezone, so a better solution would be to continue with @Mariana Menchero’s PR that removes it from the API payload but restores it on the result.

ah! thanks for clarifying that. I saw Azul's message earlier and I was about to close that PR. Let me also go back to working on it 😅

awesome, thanks @Mariana Menchero @José Morales