DateTimeOffset loses time zone offset

Open
#360 5 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
35/100
Issue type
Bug
Clarity
Mostly clear
Activity status
Stale
Tech stack
csharp
Domain
databases

Research direction

The issue does not name a file or test. Start by locating the DateTimeOffset persistence and conversion code, then reproduce the round trip described in the issue. Done means reading a stored DateTimeOffset preserves its original time zone offset while representing the same moment.

Written by the indexing model from the issue text.

Description

Feature Up for Grabs

DateTimeOffset is stored as UTC ticks. The consequence is that the data read back lacks the time zone offset; however, it still accurately represents the correct moment in time.

Store this: "2014-06-11T20: 24: 01.8325787-07: 00"
You read back: "2014-06-12T03: 24: 01.8325787+00: 00"

They represent the same moment in time, but the first contained a timezone offset.

A work around is to store a DateTimeOffset's 'Offset' and 'Ticks' separately and rebuild an accurate DateTimeOffset on read. This does mean range queries are more difficult.

Dominant language
C#
Stars
4.5k
Forks
1.4k
PR merge metrics
No merged PRs in 30d

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from praeclarum/sqlite-net

All issues in praeclarum/sqlite-net

Similar issues

More C# issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.