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

[Possible Bug] Comparison of luxon DateTime objects #278

Open
t-knapp opened this issue Aug 6, 2021 · 1 comment
Open

[Possible Bug] Comparison of luxon DateTime objects #278

t-knapp opened this issue Aug 6, 2021 · 1 comment

Comments

@t-knapp
Copy link

t-knapp commented Aug 6, 2021

Hello world,

I'd like to thank all contributors for that awesome library.

Unfortunately I think I encountered a bug, not sure: In an application, I work a lot with luxons DateTime objects (see: https://moment.github.io/luxon/#/) to represent dates. When it comes to comparison of two objects with a prop of DateTime object, the output operation array seems to be wrong.

Here is a Codesandbox attached: https://codesandbox.io/s/gracious-morse-bg1bc?file=/src/index.js

Comparing an object with null value property {time: null} and an object with DateTime property {time: DateTime.now()} gives this operation array.

0: {op: "replace", path: "/time", value: "2021-08-06T16:00:48.462+02:00"}

Looks plausible to me.

Comparing two objects with DateTime objects in time property with around 10 ms difference gives this operation array.

0: {op: "remove", path: "/time/isLuxonDateTime"}
1: {op: "remove", path: "/time/o"}
2: {op: "remove", path: "/time/c"}
3: {op: "remove", path: "/time/weekData"}
4: {op: "remove", path: "/time/invalid"}
5: {op: "remove", path: "/time/loc"}
6: {op: "remove", path: "/time/_zone"}
7: {op: "remove", path: "/time/ts"}
8: {op: "add", path: "/time/0", value: "2"}
9: {op: "add", path: "/time/1", value: "0"}
10: {op: "add", path: "/time/2", value: "2"}
11: {op: "add", path: "/time/3", value: "1"}
12: {op: "add", path: "/time/4", value: "-"}
13: {op: "add", path: "/time/5", value: "0"}
14: {op: "add", path: "/time/6", value: "8"}
15: {op: "add", path: "/time/7", value: "-"}
16: {op: "add", path: "/time/8", value: "0"}
17: {op: "add", path: "/time/9", value: "6"}
18: {op: "add", path: "/time/10", value: "T"}
19: {op: "add", path: "/time/11", value: "1"}
20: {op: "add", path: "/time/12", value: "6"}
21: {op: "add", path: "/time/13", value: ":"}
22: {op: "add", path: "/time/14", value: "0"}
23: {op: "add", path: "/time/15", value: "4"}
24: {op: "add", path: "/time/16", value: ":"}
25: {op: "add", path: "/time/17", value: "5"}
26: {op: "add", path: "/time/18", value: "6"}
27: {op: "add", path: "/time/19", value: "."}
28: {op: "add", path: "/time/20", value: "4"}
29: {op: "add", path: "/time/21", value: "6"}
30: {op: "add", path: "/time/22", value: "0"}
31: {op: "add", path: "/time/23", value: "+"}
32: {op: "add", path: "/time/24", value: "0"}
33: {op: "add", path: "/time/25", value: "2"}
34: {op: "add", path: "/time/26", value: ":"}
35: {op: "add", path: "/time/27", value: "0"}
36: {op: "add", path: "/time/28", value: "0"}

One would expect the only change to be the miliseconds numbers or just a "replace" operation for the string representation but not a whole add array items stuff.

Do you have an idea why this happens and how to fix it? Is it a bug or do I have the wrong expectations on the behaviour?

Kind regards,
Tobias

@begrs
Copy link

begrs commented Oct 31, 2023

Same issue as the newly posted #318. See there for a potential solution and workaround by me, since we had the same issue in our project.

Bump

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

No branches or pull requests

2 participants