You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'm receiving the UTC timezone in the projection as provided in the query (UTC, without any transformation):
{
"_id": "... any id ...",
"key1": {
"key2": "20171214T00:19:40.000-0000"
}
}
Can you, please, confirm, that such behavior isn't expected?
In some cases, I'm updating nested structures and it isn't a good idea to pop the time leafs in the query. How we can fix or workaround that?
The text was updated successfully, but these errors were encountered:
As far as I can tell there is no documented contracts around timestamps' offsets that lightblue returns. I agree it is surprising that it is not consistent, but for this reason I would recommend clients do not couple to any specific time offset that lightblue returns and remain agnostic to whether lightblue returns the same as the client, UTC, or system zone, even within the same response.
For example, I have the following data structure (tested with the MongoDB controller):
... and LightBlue returns -5 timezone (default at the server, non-UTC) in find queries by default.
Correct behavior
If I'm updating the item with the following query and UTC time:
I'm receiving the time transformed to the -5 timezone (non-UTC, as in the find query) in the projection:
Incorrect behavior
If I'm updating the time value with the following request (please, note the nested JSON):
I'm receiving the UTC timezone in the projection as provided in the query (UTC, without any transformation):
Can you, please, confirm, that such behavior isn't expected?
In some cases, I'm updating nested structures and it isn't a good idea to pop the time leafs in the query. How we can fix or workaround that?
The text was updated successfully, but these errors were encountered: