ah I see what you mean.
I think, but I asked Marc to conform this, is that Dapper does an implicit conversion between the DateTime value and the DateTimeOffset property in the DTO you project to and LLBLGen Pro does not. So that way your query on dapper works, and on llblgen pro it doesn't, at least not by default.
Our runtime does support implicit type conversions for resultsets, by using the
new PlainSQLFetchAspects() { PerformImplicitTypeConversions = true}
construct, as shown below in our test for your situation, but it we discovered with this that there's no implicit conversion defined in our pipeline class for this feature: it performs a lot of conversions (like short to int etc.) but not for value to DateTimeOffset.
We'll see this as a bug in v5.5 and v5.6 and will release a fix for this. With the fix the query below should work (it currently indeed doesn't).
public class TimezoneDest
{
public long Id { get; set; }
public DateTimeOffset DateCreated { get; set; }
}
[Test]
public void TimezoneConversionImplicitlyTest()
{
using(var adapter = new DataAccessAdapter())
{
var currentEntities = new LinqMetaData(adapter).Timezonetest.ToList();
if(currentEntities.Count <= 0)
{
// insert entities
var toInsert = new EntityCollection<TimezonetestEntity>();
toInsert.Add(new TimezonetestEntity() { Id = 1, DateCreated = DateTime.Now});
toInsert.Add(new TimezonetestEntity() {Id = 2, DateCreated = DateTime.Now});
toInsert.Add(new TimezonetestEntity() {Id = 3, DateCreated = DateTime.Now});
adapter.SaveEntityCollection(toInsert);
}
var results = adapter.FetchQuery<TimezoneDest>(new PlainSQLFetchAspects() { PerformImplicitTypeConversions = true},
"SELECT id as Id, date_created as DateCreated FROM public.timezonetest WHERE id > @id", new {id = 0});
Assert.AreEqual(3, results.Count);
foreach(var v in results)
{
Console.WriteLine("id:{0}, dc:{1}", v.Id, v.DateCreated);
}
}
}