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

updated_at and created_at are not UTC-based #2

Open
ghivert opened this issue May 12, 2024 · 6 comments
Open

updated_at and created_at are not UTC-based #2

ghivert opened this issue May 12, 2024 · 6 comments

Comments

@ghivert
Copy link

ghivert commented May 12, 2024

Hi!

I'm using this package, and updated_at and created_at are correctly converted in birl.Time, but they are not turned into UTC. Is it on purpose? I find it always simpler to manipulate every timestamp in UTC in backend, and manage the timezones when user interaction is needed (sending a notification, displaying the time, etc.)

@lpil
Copy link
Member

lpil commented May 12, 2024

We use whichever time zone Hex chooses to use and do not add any conversions.

@ghivert
Copy link
Author

ghivert commented May 13, 2024

OK, clear, thanks. Seems perfectly rational ha ha

@lpil
Copy link
Member

lpil commented May 13, 2024

We could pass through the timestamp strings and not use birl? Perhaps that would be clearer.

@ghivert
Copy link
Author

ghivert commented May 13, 2024

I'm not sure. I think the problem also comes from birl for being unclear.

The underlying problem is that I have an UTC time, while the time from Hex is without any timezone info. So I end up with Time(timestamp, None, Some("UTC"), None) while the package gives me Time(timestamp, None, None, None). This doesn't seems bad, but when doing birl.compare(a, b), it does not take into account the timezone, and just compares the millis without conversion. But I'm still unsure about the desired behaviour we want for datetime in general. I mean, if I'm in Paris at 16:00, and someone is in London at 15:00, it's the exact same timestamp, yet it's later in Paris than in London. 🤔

Maybe it's worth a discussion in birl?

@lpil
Copy link
Member

lpil commented May 13, 2024

Sounds like a birl bug if they're not taking timezones into account. I'd be happy to either keep this library as-is, or remove the birl usage.

@ghivert
Copy link
Author

ghivert commented May 13, 2024

I'll open a discussion on burl to see if we can find a best solution. As of now, let's not change it. Actually I like the idea of not having to deal with datetime parsing and getting a birl Time directly.

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