Configure default DateTimeKind when no timezone information given

[2moveit]

All TypeProviders will convert the DateTime string"03.01.2016 00:00:00" automatically to DateTimeKind.Local.
https://github.com/fsharp/FSharp.Data/blob/b5df1ca30f5bb7749c4fd340b61f1b7fc43fb547/src/CommonRuntime/TextConversions.fs#L103-L104

I think it's correct that it is set to DateTimeKind.Local as of ISO 8601 although the default of .NET DateTime() is Kind.Unspecified.
Although you're not doing it explicitly you usually want to use it that way and in 90% of the case it will be correct.

In my case I get a CSV file for price lists from different countries (timezones). The date has the mentioned form "03.01.2016 00:00:00".
So there is no information about the timezone. Although the other system should've used the ISO 8601 format there are many reasons that this might happen especially when using the .NET DateTime class and not being aware of timezones.

As mentioned there are edge cases where you have to do an additional manual convertion to set it to DateTimeKind.Unspecified. E.g by new DateTime(old.Year, old.Month, old.Day).
That is a little bit hacky and so I like to be able to configure the TypeProvider to use Kind.Unspecified as default if the there is no information of the timezone given.
So my suggestion is to make this configurable when initializing the TypeProvider.

Before trying to contribute (where I might need your help) I'd like to discuss this before starting it as it will effect all TypeProviders. Suggestions how to implement it are welcome.

[eugbaranov]

I wonder if allowing to specify and honoring DateTimeStyles would be a better solution?

[ovatsus]

Maybe you could have a AssumeLocalTimeWhenUnspecified boolean static parameter which is default to true?

[github-actions]

🤖 This is an automated response from Repo Assist.

Thanks for raising this — it's a valid pain point! Here's some context and options:

Current behaviour

In TextConversions.fs, when a DateTime string is parsed without timezone information, the result is promoted to DateTimeKind.Local:

| ValueSome d when d.Kind = DateTimeKind.Unspecified -> new DateTime(d.Ticks, DateTimeKind.Local) |> Some

This is intentional but can be surprising when dealing with multi-timezone CSV files.

Workaround available today

If your dates contain no time component (e.g. 2016-03-01), you can annotate the column as "date" in the Schema parameter to get System.DateOnly values, which avoids the timezone issue entirely:

type Prices = CsvProvider<"data.csv", Schema="Date (date), Price (decimal)">

If you do have date+time values and want full timezone awareness, annotate the column as "datetimeoffset" to get System.DateTimeOffset instead:

type Prices = CsvProvider<"data.csv", Schema="Timestamp (datetimeoffset), Price (decimal)">

A potential enhancement

A PreferDateTimeOffset static parameter could be added to automatically infer all date-time columns as DateTimeOffset instead of DateTime, similar to the recently-added PreferFloats parameter for CsvProvider. This would be the cleanest solution for the use case described here. Contributions welcome!

Generated by Repo Assist

To install this agentic workflow, run

gh aw add githubnext/agentics/workflows/repo-assist.md@69c1ee19e39e6aaba35519aafefb5cbf314de323

[github-actions]

🤖 This is an automated response from Repo Assist.

I've submitted a draft PR implementing PreferDateTimeOffset for CsvProvider, JsonProvider, and XmlProvider. When set to true, date-time values that lack an explicit timezone offset are inferred as DateTimeOffset (with the local UTC offset) rather than DateTime.

Usage:

type Prices = CsvProvider<"prices.csv", PreferDateTimeOffset=true>
// DateTime columns become DateTimeOffset — DateTimeKind is no longer ambiguous

type Events = JsonProvider<"events.json", PreferDateTimeOffset=true>

The implementation is a post-inference rewrite: the inferred type tree is walked after inference and DateTime is replaced by DateTimeOffset throughout. No runtime changes are needed — TextRuntime.ConvertDateTimeOffset already falls back to parsing as DateTime and converting with the local offset, so existing strings like "2023-06-15T10:30:00" parse correctly.

See the PR for full details.

Generated by Repo Assist

To install this agentic workflow, run

gh aw add githubnext/agentics/workflows/repo-assist.md@69c1ee19e39e6aaba35519aafefb5cbf314de323

Warning

⚠️ Firewall blocked 1 domain

The following domain was blocked by the firewall during workflow execution:

• www.google.com