A few months ago I developed a web API with C# and ASP.NET
I did not know I would have time issues when using the API in an Android app. It led me to learn two different time systems UNIX and Windows. Since there is not much information I could find concerning this I decided to share my solution/approach to this setback.

The easiest way to solving this is may be sending date as text. Something like this "2013-12-19" then using regular expressions/extensions to get the date from it. The problem comes when the date comes in a wrong format. What do you do with different representations of the same date like 2013-12-9 that should have been written as 2013-12-09 for the RegEx to work? This was my particular problem.I know there are libraries out there for dealing with Java time but I did not get an easy one to use in my case. So I dived in to develop a solution. This is what I learned:

a) Java uses UNIX time while C# uses WINDOWS time (for the latter it's obvious)

Why would these two have different ways of representing time? Why not the same way for everyone? I hope it's not another patent that has brought about this. Well, I cannot change it, so I will work with it that way.

b) UNIX time starts on January 01, 1970 while WINDOWS time starts on January 01, 1601.

Who cares when what time start when? Time is time and it's time for everyone everywhere. It's just the actual time that differs due to geographical location. Is one party trying to be unique here? "Hey, we can go really back in time?"

c) Querying the Java time for a long integer you get millis whereas in C# you get the ticks

What are ticks and what are millis? Windows uses ticks which are more accurate. There are 10,000 ticks in one millisecond. So in one second, we have about 10,000,000 ticks! What is this precision for? Anyway precision is always a good thing to brag about. Nothing more for me

d) Despite WINDOWS time starting on January 01, 1601 the DateTime class in C# starts on January 01, 0001.

Was there such a year? If there was, I believe there is nothing we need to document with that precision!

To sort out this trouble, I used the same classes in C# for serialization to JSON. Specifically NewtonSoft, available via NuGet. It is a very simple and handy library. If you set the serialization settings right, it will give you date in UTC format. I like that; that's why I use it. In the Android app, I used Google's handy library, GSON for de-serialization.
All that is shown works fine and is shown in the code. The problem arose when I needed to filter data.
To communicate from the android app (Java) to C#, I had to adjust to the time differences. The date difference between January 01, 1970 and January 01, 0001 is what I am calling the offset. Add the offset before sending the data to the webapi.
The offset it 621,355,968,000,000,000 ticks or 62,135,596,800,000 millis.
In case you need to revert to Java time, I have added a handy method for that.

You can get all the code