In a WinRT (Windows 8.1 Store App) project, I'm using the SQLite.Net-PCL and SQLiteNetExtensions NuGet packages to store data in a local SQLite database file.
Several of my data models (aka tables) contain properties of type DateTimeOffset
. The aim is to store these without losing the offset information. (Reason for this is that the user can enter timezone information while specifying dates / times, and this information must be stored in the database.)
I'm aware of the storeDateTimeAsTicks
parameter that can be set while creating the SQLiteConnection
, setting this to false
forces all DateTime
properties to be stored as text in ISO format - however, this has no consequences on DateTimeOffset
properties, as these are always automatically converted to UTC and stored as a number representing ticks.
I can think of the following 4 approaches:
- Manually convert
DateTimeOffset
tostring
properties and store these, or - extract the
DateTime
and offset (asTimeSpan
date type) parts of theDateTimeOffset
, and store these in two separate columns,
=> but for both approaches, I'll need to add additional properties to the data model, flag the original DateTimeOffset
properties with the [Ignore]
attribute, and handle manual conversion (in both directions) - since I'd need to apply this to a lot of different data model classes, it seems too hard to maintain.
- Store the
DateTime
andTimeSpan
(offset) parts of theDateTimeOffset
in two columns of a separate table, and maintain references to this separate table
=> but in this case I'd need to define a custom data type (in order to specify how the DateTime
and TimeSpan
parts should be stored), and cannot use the default .NET DateTimeOffset
type
- Use SQLiteNetExtensions'
TextBlob
attribute to somehow serialize theDateTimeOffset
to a single text column
=> but this feels somewhat hacky, I'd need to make sure that only SQLiteNetExtensions' extension methods are used for DB insert / update, and I'd still need an additional string
property on all the data model classes...
So, my question is: Is there a more straigtforward, obvious solution that I'm missing?
DateTimeOffset
is almost never the same asDateTime
+ "user timezone". In fact, the part most people care about is the timezone, or often the behavior surrounding DST (with the offset being a secondary consideration). If you're storing absolute, always maps to the same instant, times, then the actual zone is somewhat unimportant. If, on the other hand, any future date/times might reasonably change if the offset does (if DST is adjusted, usually), like for calendar/scheduling programs, storing the offset alone is unlikely to help completely. – Talithatalk