The Breaking Changes Wishlist for 1.2

[Oren Eini (Ayende Rahien)]

We are _considering_ some breaking changes to 1.2

In particular, there are some things that I don't like in the way we are handling dates in indexes, and a bunch of other relatively minor stuff, which we can't current do due to backward compatibility.

That led me to think that there are probably additional stuff that you are probably gnashing your teeth about that we can't fix because of backward compact.

Does anyone have major things that they want to change in the way RavenDB works?

[Itamar Syn-Hershko]

We were discussing the possibility of moving Facets and Suggests to a "Search" bundle along with the lesser-known MoreLikeThis feature. Your opinion?

[Ryan Heath]

When you say 'bundle' do you mean a separate nuget or a serverside bundle?
Sidenote, how would this work with Raven AppHarbor when it will become
a serverside bundle?

// Ryan

[Oren Eini (Ayende Rahien)]

Leave aside RavenHQ concerns for now, it isn't relevant for the discussion.

[Ryan Heath]

Yup, its sidetracked. Now I use features like Search solely from the
ravenclient perspective, how would that change
when it will be put into a separate 'bundle' whether or not nuget or serverside?

// Ryan

On Wed, Apr 11, 2012 at 10:58 AM, Oren Eini (Ayende Rahien)

[Oren Eini (Ayende Rahien)]

I am not sure that it would. Those features are pretty commonly used for major scenarios, I don't know whatever we will do an internal move (transparent to the clients) to an "internal bundle", solely so we would have better code structure.

But I do know that I want to continue making facets and suggestions easy to use and accessible.

[Itamar Syn-Hershko]

Server-side bundle with complementary client bundle with extension methods

On Wed, Apr 11, 2012 at 11:47 AM, Ryan Heath <ryan.q...@gmail.com> wrote:

[Matt Warren]

I agree with this, although I'm probably a bit biased!

I don't think making facets something you need to "turn on" or enable is a good idea. From the amount of mentions on this group it seems to be a pretty widely used feature. What happens internally is another matter, splitting to code up makes some sense, although the majority of the facet code is separate from the core indexing code already.

[Troy]

Not sure this would be a breaking change... but can we get an overload on the DatabaseCommands.Delete to be generic like load ... such as: DatabaseCommands.Delete<Company>(1)

[alwin]

It would be great if numbers would sort as numbers by default, and not
as text.
OrderBy(a number) would then become consistent with the default
ordering of numbers.
The current behavior is counter-intuitive.

For example, the default sort order for a decimal property should be
decimal, not string.
Related thread: http://groups.google.com/group/ravendb/browse_thread/thread/4045b5bf1c717069
Related documentation: http://ravendb.net/docs/client-api/querying/static-indexes/customizing-results-order

On Apr 10, 11:45 am, "Oren Eini (Ayende Rahien)" <aye...@ayende.com>
wrote:

[Oren Eini (Ayende Rahien)]

That won't be possible, because it requires access to the conventions, which does not exists at that level.

[Oren Eini (Ayende Rahien)]

Alwin,

when you do OrderBy / OrderByDescending in the Linq API, that works.

[Jim Baltika]

Hi Oren,

I think, the Raven team needs to revise Raven.Client namespace organization a little bit to make easier learning curve and programming junior/mid-level programmers, let me explain that I noticed and observed. I read your article about  field boosting. So I decided to mimic functionality. It took me sometime to find the Boost(double) extensions method. Its under Raven.Client.Linq.Indexing namespace. So I thought maybe I suck. Ok. So observed my team a little bit. They also could not find other COMMON calls as well very often, because they located somewhere like in namespace Raven.Client.Linq or other namespace. So my point is why developer need to know all these namespaces to implement common functionality? The Raven team work on this project EVERY DAY and knows there and that to include, but other will struggle. Right now the Raven.Client.Lightweight has 20 namespaces (sometimes one class in namespace) and I think to make RavenDb learning curve even less difficult the Raven DB team need to revise Raven.Client.Lightweight organization for RavenDB course 101 and make emphasis on Visual studio Intellisense. I  think for client side 90% common implementation developer must be familiar with 2-3 namespaces. By the way my to be clear, all my suggestions don't apply to any other raven project. 

So I would ask the questions my self like 'How many times I will use in commercial web project like DocumentStore, Lazily, AbstractGenericIndexCreationTask and How many EmbededDocumentStore and ect?

[Matt Johnson]

This is a very minor thing, but I don't get the naming of
"AbstractIndexCreationTask". Why not just call it something like
"StaticIndex"?

-Matt

On Apr 10, 2:45 am, "Oren Eini (Ayende Rahien)" <aye...@ayende.com>
wrote:

[Itamar Syn-Hershko]

Jim,

We mostly leverage ReSharper, so hardly notice that. We will look into it, worse case we will have that properly documented 

Thanks for the feedback

[Itamar Syn-Hershko]

Because it is not a static index, but an index creation task... Maybe the Abstract word there is a bit too much...

[Matt Johnson]

> In particular, there are some things that I don't like in the way we are

> handling dates in indexes...

Can you please elaborate on this? My app is heavily concerned with
dates/times, so I'm quite interested in what changes you have in mind.

One thing that is a challenge now is when we use DateTimeOffset
fields, which are serialized in json as ISO-8601 with an offset. Due
to the lexographic search, it's impossible to get a proper index with
these sorted properly or for range queries. Right now, we're dealing
with this by separately saving them as an integer (seconds since the
UTC unix epoch) and indexing that instead. It would be nice if this
was handled internally.

Is that the issue you are concerned with as well? Or is there more to
it than that?

-Matt

[Oren Eini (Ayende Rahien)]

Actually, right now we have a conflict in R# because of namespaces, if you have System.Linq imported, it won't import Raven.Client.Linq.

[Oren Eini (Ayende Rahien)]

Matt,

ISO-8601 _is_ lexigraphically searchable.

That is actually how I want to save the dates.

For date time offset, I want to save the UTC time.

[Matt Johnson]

Yes, it is lexicographically searchable / sortable with regard to the
date and time portion, but not with regard to the offset. If you are
saving all times as UTC, then DateTime will work and there's no need
for an offset. Or you can use DateTimeOffset with a zero offset.
Even if you use DateTimeOffset with some other offset, it still works
ok as long as all of the offsets are the same. The problem is when
you store several DateTimeOffsets with DIFFERENT offsets and expect
them to be sorted with the offset applied. If you simply compare two
datetimeoffsets in c#, it does indeed sort that way. But as ISO
strings, the offset is pretty much useless when it comes to sorting/
searching.

It's not unsolvable, it just means that if you need to search by local
time, it works as is. If you need to search instantaneous times from
different offsets, then you have to store them either as UTC or an
equivalent numerical value.

All I was saying as far as future requests go, is that it would be
nice to have an option for sort-order on an index for datetime and/or
datetimeoffset the same way you have the options for integer and
decimal. When chosen over the default string sort, perhaps the offset
could be taken into account such that they sort the same way they
would in c#. It is slightly counter-intuitive that when you write a
linq-to-raven query that you wouldn't get the same sorting as if it
were straight linq-to-objects.

-Matt


On Apr 14, 10:38 pm, "Oren Eini (Ayende Rahien)" <aye...@ayende.com>
wrote:

[Matt Johnson]

Sorry, I forgot the second part. you said "For date time offset, I

want to save the UTC time.

I hope you don't mean that you would strip the offset away and save as
UTC? That would be very bad. If all you care about is UTC, then use
a DateTime with .Kind=Utc. We very much need and depend on the
datetime and offset being saved as-is with no conversion if we choose
to use DateTimeOffset. I have several use cases if you are
interested.

-Matt

[Oren Eini (Ayende Rahien)]

Matt,

What is the meaning on sorting on different times in different time zones?

[Oren Eini (Ayende Rahien)]

Matt,

I meant, for indexing purposes, we would index the UTC time, and search on UTC time.

We would save the _document_ as local time.

[Oren Eini (Ayende Rahien)]

Another thing that I want to try it to see if we can internalize our own Json.NET dependency.

It causes some non trivial amount of friction for users, it seems. I am not sure how to do this yet, but I would love to get some ideas.

[Itamar Syn-Hershko]

Compiling JSON.NET into Raven.Json?

[Oren Eini (Ayende Rahien)]

Yeah, I am not really sure that I want to _do_ that.

[Itamar Syn-Hershko]

Ok, the other alternative is to lazy load JSON.NET, maybe dynamically..

Why can't this be resolved with assembly redirects, btw?

[Oren Eini (Ayende Rahien)]

One of the things that drive me crazy right now with json.net is that he adds abstract methods to things like JsonReader, which means that even with assembly redirect, you would get MethondNotFoundException

[Matt Warren]

Can you embedded the relevant dll into a RavenDB dll as a resource and then use the technique here?

I've used the before to make sure different version of a dll is used under XP compared to Vista.

[Oren Eini (Ayende Rahien)]

I can, sort of, but that is just another way to do interning, and I am not sure that I want to go there, anyway.

[Damian Hickey]

I was going to bring up this exact topic. I've been considering the remaining dependencies and references when one references the RavenDB.Client & RavenDB.Embedded packages. Currently focusing on logging right now.

I think this is the only direction you can go... You can't ILMerge /internalize because types are exported via Raven.Abstractions etc and the user will end up with namespace collisions and type ambiguity.

[Damian Hickey]

This approach only recommend for .exes and not .dlls.

[Damian Hickey]

I've taken a similar approach with the logging abstraction but that is a simple interface.

> assembly redirects

A fragile hack, imho, which can (often) result in runtime exceptions. Json.Net is such a critical part of Raven, if it were up to me, I wouldn't want to rely on that and the support issues that can (and will) arise from that.

Unless your CI runs your tests against all published versions of JSON.net.

[Oren Eini (Ayende Rahien)]

Damian,

JSON.Net is actually pretty much use everywhere inside RavenDB.

[alwin]

OK I will try this out again.
Couple of months ago I had to create a static index with sort order,
because a dynamic index OrderBy would always sort alphabetically.
It is great if this has been fixed since then!

On Apr 14, 12:33 pm, "Oren Eini (Ayende Rahien)" <aye...@ayende.com>
wrote:

> Alwin,
> when you do OrderBy / OrderByDescending in the Linq API, that works.
>
>
>
>
>
>
>
> On Sat, Apr 14, 2012 at 4:08 AM, alwin <alw...@gmail.com> wrote:
> > It would be great if numbers would sort as numbers by default, and not
> > as text.
> > OrderBy(a number) would then become consistent with the default
> > ordering of numbers.
> > The current behavior is counter-intuitive.
>
> > For example, the default sort order for a decimal property should be
> > decimal, not string.
> > Related thread:

> >http://groups.google.com/group/ravendb/browse_thread/thread/4045b5bf1...
> > Related documentation:
> >http://ravendb.net/docs/client-api/querying/static-indexes/customizin...

[Damian Hickey]

I've recently added a comment regarding this on RavenDB-178.

I am of the opinion that true semver is a fallacy on .net. Just about every change is potentially a breaking one. And then include internal behaviour that can break, even if API doesn't change. There isn't the tooling in .net to easily detect and catch these breaks. Perhaps with NDepend, but not widely used.

At this point I think your options are:

A) Rely on json.net semantic versioning and depend on patch range, but also set up CI configuration to build against all published versions within this patch range. This reduces friction for customers but only until the next minor release of json.net. It's pragmatic because you will catch inadvertent breaking changes before your customers (and support line) does.

B) Import the json.net code base and re-namespace. Opens up the possibility of incompatibility between serializers. I can't say how big a prob that could end up being. Off the top of my head, ServiceStack took this approach with it's FluentValidation dependency.

It's a difficult problem. I too would love any betters idees.

Fyi, my experience in this area is a software product that has dependency on 60+ oss packages and counting (not all in one project obviously) and I'm experiencing this 'diamond' dependency pain on a near daily basis. Thus, my recent contributions to Raven's packaging, dependency and deployment story.

[Damian Hickey]

Oren,

>Json.Net is such a critical part of Raven

I know! :)

[Matt Johnson]

> I meant, for indexing purposes, we would index the UTC time, and search on
> UTC time.
> We would save the _document_ as local time.

YES - that would work very well. I would make the following
assumptions:

If I store a DateTime without an offset such as "2012-04-15T10:00:00"
that it would be saved and indexed without any conversion.

If I store a DateTimeOffset such as "2012-04-15T10:00:00-07:00" that
it would be saved in the document without conversion, but would be
indexed as UTC "2012-04-15T17:00:00Z".

When I query an index by a DateTimeOffset, that the query engine would
adjust input parameters to UTC before comparing against the index, so
I don't have to think too much about what's happening behind the
scenes.

That all of this would depend on something like
Indexing.SortOptions.DateTimeOffset, which would be the default when
using this datatype.

> What is the meaning on sorting on different times in different time zones?

This is how it ends up working today due to the lexicographical sort.
The only use case is when you want the search to be ignorant of the
timezone. There aren't very many scenarios that require that. The
other method would be much better. If the SortOptions is selectable,
this behavior could still be used if SortOptions.String was selected
instead.

-Matt

[Damian Hickey]

Possible idea?

Pseudo script:

1. ildasm /out=NewtonSoft.Json.il NewtonSoft.Json.dll
2. Find-Replace NewtonSoft.Json.il 'NewtonSoft.Json' 'Raven.Json'
3. ilasm /out=Raven.Json.dll /dll NewtonSoft.Json.il

Just did this manually and it appears Raven.Json.dll turned out ok when browsed in ILSpy and referenced in a csproj.

Could be feasible if you never need to fork NewtonSoft.Json?

On Sunday, 15 April 2012 12:44:45 UTC+1, Oren Eini wrote:

[Oren Eini (Ayende Rahien)]

Yeah, I am not sure how much I like it, but yeah, we might just end up doing this.

[Tobi]

Wouldn't this terribly break the debugging symbols?

Why not just take the Newtonsoft.Json source, replace the namespaces with
a script and add the changed source to RavenDB. On the next
Newtonsoft.Json release just run the same script on the new sources.

It might even be feasible to maintain a fork from https://github.com
/JamesNK/Newtonsoft.Json. Possible merge conflicts shouldn't be to hard to
resolve if only the namespaces are changed.

On 16.04.2012 08:02, Oren Eini (Ayende Rahien) wrote:

> Yeah, I am not sure how much I like it, but yeah, we might just end up
> doing this.
>
> On Sun, Apr 15, 2012 at 10:53 PM, Damian Hickey <dhi...@gmail.com
> <mailto:dhi...@gmail.com>> wrote:
>
> Possible idea?
>
> Pseudo script:
>

> 1. ildasm /out=NewtonSoft.Json.il <http://NewtonSoft.Json.il>
> NewtonSoft.Json.dll
> 2. Find-Replace NewtonSoft.Json.il <http://NewtonSoft.Json.il>
> 'NewtonSoft.Json' 'Raven.Json'
> 3. ilasm /out=Raven.Json.dll /dll NewtonSoft.Json.il
> <http://NewtonSoft.Json.il>

[Damian Hickey]

This is just basically IL rewriting. Other IL rewriters (ccrewrite/ilmerge/etc) seem to handle pdbs just fine.

I actually spiked out your approach first (see https://github.com/damianh/Newtonsoft.Json/tree/Ravenize ) and while it sorta worked, there are some items that will bump the maintenance cost of doing so such as merging (as you mentioned), edge cases in string literals (InternalsVisibleTo, DynamicWrapper.cs), strong names, and ensuring that the tests pass. That was just what I encountered last night.

What appealed to me about the IL rewrite approach is that you're taking a released and tested assembly and just re-namespacing. It simpler maintenance wise, but it could be deceptive and broken in actual usage.

The third approach is to import the json.net code base, including tests, into the Raven repo and create a script to periodically synchronize changes.

I don't yet know which is the better approach. Each one has advantages and trade-offs. Further exploration required.

[Oren Eini (Ayende Rahien)]

Right now we are testing if we can just import the code using git subtree and that would work.

[Damian Hickey]

That'll should allow you to import the source all right. I'm very interested to see how you maintain the namespace and related changes on top of that. (I'm presuming you'll still need to maintain some sort of fork.)

I might flesh out my idea a bit more, as a matter of personal interest.

[Oren Eini (Ayende Rahien)]

It is a "fork", in the ravendb repository.

We modify the namespace and see if we can actually make this work. merging shouldn't be an issue, I think.

[Fitzchak Yitzchaki]

You can look on the current form of the code on my fork:

https://github.com/fitzchak/ravendb

[Damian Hickey]

Nice. I did a powershell script to alter the assembly with cecil (nothing new there) but this would be could be better in long run, especially with respect to debugging.

[Fitzchak Yitzchaki]

James (the creator of Json.NET) points out the internaling the Json.NET code will result in the following breaking change:

Any reference to JsonIgnore, JsonProperty, JsonConvert, JsonObject, JsonArray attributes (and maybe more) would break and the user will be required to use the internal namespace of this attributes. (Which will be like Raven.Internal.Newtonsoft.Json).

Well this is a breaking change, which we didn't took into account initially. What do you think about it?

[Itamar Syn-Hershko]

Why does the internaling process have to involve changing the namespace?

We can compile the sources using their original namespaces into Raven.Json, which in turn has its own wrappers around it, which we use. The change will be transparent.

[Tom Cabanski]

This kind of breaking change would cause all sorts of problems.  I really think you are better off leaving external references external as a general rule.

Tom Cabanski
Blinds.com
832-766-5961

My profiles: Facebook LinkedIn
Contact me: t...@cabanski.com tom.cabanski t...@cabanski.com

Latest Blog Post: Top Ten Reasons to Avoid Taking Advanced Distributed System Design with Udi Dahan

Latest tweet: What does a duct tape programmer do when the duct tape runs out? Follow @tcabanski Reply Retweet   21:00 Apr-16

  Get this email app!  

[Oren Eini (Ayende Rahien)]

We have to modify JSON.Net to resolve some things.

And we have to allow users to customize themselves using JSON.Net options.

[Oren Eini (Ayende Rahien)]

Which brings us back to the same problem as before, just managing this is becoming really hard.

[Itamar Syn-Hershko]

Following up on this:

This will be a breaking change in 1.2.

We will compile the entire Json.NET sources into one of the Raven assemblies, under a custom namespace.

You will have to change the using statements in your code to point to that namespace instead of Newtonsoft.Json.*

The idea behind this is to avoid depending on external release cycles, and to be able to fix bugs on ourselves, stuff that wasn't accepted upstream

On Tue, Apr 17, 2012 at 3:24 PM, Fitzchak Yitzchaki <fitz...@hibernatingrhinos.com> wrote:

[Jim Baltika]

Hey guys,

I faced the same problem a some time ago. Check it out it, works for my team fine. The Short story. We are building sites using Sitecore CMS which uses JSON.NET 3.51 (and it not open source and can' be upgraded as it will break everything), also we have Raven JSON.NET 4.0.8 and our libraries uses the JSON.NET 4.5. So we got JSON.NET source changed  the build target names like Vodca.Sdk.Newtonsoft.Net and added reference alias not as global (default) but  with out name SDK and modified code (example below) . Now If I need a new version to run from JSON.NET I update source rebuild each time. This way i don't need care about changing custom namespaces or joining the changes , no maintenance problem and all three 'JSON.NET' work together :)

extern alias SDK;
 
namespace Vodca
{
    using System.Diagnostics.CodeAnalysis;
    using SDK::Newtonsoft.Json;
 
    /// <summary>
    ///     The JSON extension methods
    /// </summary> 
    public static partial class Extensions
    {

[Oren Eini (Ayende Rahien)]

The problem is that:

a) it is complex

b) requires users to know really strange stuff about the C# spec

c) doesn't work well in R#

[Matt Warren]

What about changing the behaviour when indexing numerial values?

At the moment if you have an index that contains and int/long/decimal etc, it's indexed in 2 fields, for instance Age=2 becomes

1. Age = 2
2. Age_Range = 0x00000002 (depending on type, int,long etc)

I believe this is so you can do exact comparisions against the "Age" field and range comparisions against the "Age_Range" fields. For instance:

• Age:2
• Age_Range:[0x0000000 TO 0x00000010]

Why not just store the "_Range" field and then make the Client API convert "Where(x => x.Age == 2)" into "Age_Range:0x00000002"

This would save storing 2 fields in the Lucene index, which would save 

[Oren Eini (Ayende Rahien)]

It isn't that important and it would break querying in the studio

[Matt Warren]

Good point

[Chris Marisic]

The API usages of As<T> and AsProjection<T> are extremely confusing to be used appropriately: http://issues.hibernatingrhinos.com/issue/RavenDB-269

[Rémy van Duijkeren]

I also don't get the naming of "AbstractIndexCreationTask". When going deeper into RavenDB I understand that is an index creation task for RavenDB, but is it something that a user most know? Does a user use it as a task or as an index (the RavenDB documentation talks about index, if I remember correctly)?

 

Removing the Abstract would be a step in the good direction, I think.

 
On Saturday, April 14, 2012 8:20:54 PM UTC+2, Itamar Syn-Hershko wrote:

Because it is not a static index, but an index creation task... Maybe the Abstract word there is a bit too much...

On Sat, Apr 14, 2012 at 9:17 PM, Matt Johnson <mj1...@hotmail.com> wrote:

This is a very minor thing, but I don't get the naming of
"AbstractIndexCreationTask".  Why not just call it something like
"StaticIndex"?

-Matt

On Apr 10, 2:45 am, "Oren Eini (Ayende Rahien)" <aye...@ayende.com>

[Mauro Servienti]

AbstractIndexDefinition, for the server is a creation task but for the developer is a definition.
I like the Abstract prefix because it enforces the fact that you must inherit from it.

.m
_____________________
It's all about trust...

---

From: Itamar Syn-Hershko
Sent: 07/05/2012 16:41
To: rav...@googlegroups.com
Subject: Re: [RavenDB] Re: The Breaking Changes Wishlist for 1.2

How would you as a user name that thing?

[Itamar Syn-Hershko]

How would you as a user name that thing?

On Mon, May 7, 2012 at 4:07 PM, Rémy van Duijkeren <remy.van...@gmail.com> wrote:

[Rémy van Duijkeren]

For me it would be more logic to call it something like: IndexDefinition, StaticIndex, NamedIndex,...

 

IndexDefinition would probably be the best description, because your are only describing they index: it's not the index self. In contradiction to Mauro I'm not so found of the Abstract prefix, but that is, I think, a personal thing.

[Oren Eini (Ayende Rahien)]

IndexDefinition already exists, it is the... well, definition of the index.

This is what AICT creates, after all.

[Itamar Syn-Hershko]

The IndexDefinition class should then be the one with the complex naming IMO

[Bryan Johns]

Personally I prefer descriptive class/property/method names. I'd be happy
with any of the following:

AbstractIndexDefinitionFactory,
IndexDefinitionFactoryBase,
IndexCreationTaskBase,

or just leave it like it is... :)

The point being that the prefix "Abstract" or the suffix "Base" identify
it as a class that must be inherited. No need to dig through the
documentation to find out that it must be inherited.

--
Bryan Johns
K4GDW

"When plunder becomes a way of life for a group of men living together in
society, they create for themselves in the course of time a legal system
that authorizes it and a moral code that justifies it." --Frederic Bastiat

> -----Original Message-----
> From: rav...@googlegroups.com [mailto:rav...@googlegroups.com] On
> Behalf Of Itamar Syn-Hershko
> Sent: Tuesday, May 08, 2012 5:20 PM
> To: rav...@googlegroups.com
> Subject: Re: [RavenDB] Re: The Breaking Changes Wishlist for 1.2
>

[Rémy van Duijkeren]

On Wednesday, May 9, 2012 12:19:50 AM UTC+2, Itamar Syn-Hershko wrote:

The IndexDefinition class should then be the one with the complex naming IMO

 

I grant that :o). Or call it the next one in my list: StaticIndex...

 

I am mentioning this, just like Matt, because it throw me off, the first few times I had to use it. I think this is because of the following reasons:

- Coming from SQL Server, I don't see the connection with Indexes to Tasks.

- When creating Task, I expect them to run, but the method for RavenDB is CreateIndexes(Task)...

 

Also in your blog post http://ayende.com/blog/4668/ravendb-defining-indexes, you are talking about Index Definitions to communicate the idea.

 

Also only after reading the post of Gamlor (I first read the RavenDB docs) I was understanding RavenDB (really great and fun explanation!). The post http://www.gamlor.info/wordpress/2011/07/ravendb-queries-and-indexes/ is talking about Dynamic- and StaticIndexes and then I right away get the concept. 

 

p.s. For using Factory in the name, I don't get that: Your than communication other concept. And for using Abstract or Base, see http://stackoverflow.com/questions/429470/naming-conventions-for-abstract-classes for which I can relate to the highest rated answer.

[Wagner Ignacio Pinto Junior]

Maybe I'm too late here :(

Something that really bothers me is DateTime serialization, I would like RavenDb to treat DateTime as SQL Server does, not timezone or DateTimeKind information, therefore DateTime values retrieved from RavenDb correctly have Kind = DateTimeKind.Unspecified.

[Joseph Daigle]

You can change that yourself with a custom json transformer.

[Oren Eini (Ayende Rahien)]

Yes,

Note that we respect what you give us, but assume that Unspecified = Local, because there really isn't any other way to go here.

[Chris Marisic]

For the love of god never let a user store DateTime.Unspecified, assume anything, it's better than where it was.

[Justin A]

DateTime is always UTC dates for me. Simple. 

[Bryan Johns]

> -----Original Message-----
> From: rav...@googlegroups.com [mailto:rav...@googlegroups.com] On

Perfectly reasonable when your users, or data points, need a common date
time reference that spans time zones. However, if the user base is limited
to a single time zone and is unlikely to ever expand beyond that, having to
convert to or from UTC with every read or write is a little unnecessary
overhead. Sure, it's not much, but when you're running on commodity
hardware those little bits add up.

--
Bryan Johns
K4GDW

"Today, when a concerted effort is made to obliterate this point, it cannot
be repeated too often that the Constitution is a limitation on the
government, not on private individuals -- that it does not prescribe the
conduct of private individuals, only the conduct of the government -- that
it is not a charter for government power, but a charter of the citizen's
protection against the government." --author Ayn Rand (1905-1982)

[Oren Eini (Ayende Rahien)]

That is why we keep the value in the format you give us, and give you the option to change that.