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

Timezone offset information lost when reading a ChronoDateTimeWithTimeZone #2319

Open
pierre-wehbe opened this issue Aug 7, 2024 · 1 comment

Comments

@pierre-wehbe
Copy link

Description

After successfully saving a timestamp of type ChronoDateTimeWithTimeZone to my SQLite and Postgres DB with timezone offset information (eg: 2023-01-01 00:00:00 07:00), the timezone offset information ( 07:00) is lost on read. I get "2022-12-31T17:00:00 00:00"

Steps to Reproduce

struct Model {
   ... (pk, other properties)...
   pub timestamp: ChronoDateTimeWithTimeZone
}

Insert the following

Model { timestamp: DateTimeWithTimeZone::parse_from_rfc3339("2023-01-01 00:00:00 07:00").unwrap() }

The read the value after insertion

Expected Behavior

Should get "2023-01-01 00:00:00 07:00"

Actual Behavior

Getting "2022-12-31T17:00:00 00:00"

Reproduces How Often

Always reproducible

My guess is that TryGetable is not implemented to read non-UTC timezone offset.

Versions

└── sea-orm-migration v1.0.0-rc.7
│       ├── sea-orm v1.0.0-rc.7
│       │   ├── sea-orm-macros v1.0.0-rc.7 (proc-macro)
│       │   │   ├── sea-bae v0.2.0 (proc-macro)
│       │   ├── sea-query v0.31.0-rc.9
│       │   │   ├── sea-query-derive v0.4.1 (proc-macro)
│       │   ├── sea-query-binder v0.6.0-rc.4
│       │   │   ├── sea-query v0.31.0-rc.9 (*)
│       ├── sea-orm-cli v1.0.0-rc.7
│       │   ├── sea-schema v0.15.0-rc.7
│       │   │   ├── sea-query v0.31.0-rc.9 (*)
│       │   │   └── sea-schema-derive v0.2.0 (proc-macro)
│       ├── sea-schema v0.15.0-rc.7 (*)
├── sea-orm v1.0.0-rc.7 (*)
├── sea-orm-migration v1.0.0-rc.7 (*)
@pierre-wehbe
Copy link
Author

pierre-wehbe commented Aug 7, 2024

Note: It might be related to a sqlx problem.
I opened a PR over there in case you guys can help take it to the finish line.
launchbadge/sqlx#3411

-- Update:
That PR doesn't seem to solve the issue unfortunately

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

1 participant