We Keep Coding

Get Milliseconds from Ticks in DateTime c# [duplicate]

This question already has answers here:
How do you convert epoch time in C#?
(14 answers)
Closed 2 years ago.
I have a simple DateTime object, equal to the date: 11/1/2020 8:11:14 AM.
I want to convert it to milliseconds so I do:
myTimestamp?.Ticks / TimeSpan.TicksPerMillisecond.
I get 63739786274788, which seems correct from the pure calculation perspective.
However, when I input it into one of the online converters to validate, I get the date Wed Nov 01 3989 01:11:14, which is of course way off.
Questions:
What is this number 63739786274788 if not time in ms?
How do I get "normal" timestamp in ms?

In .NET, DateTime ticks are based on an epoch of 0001-01-01T00:00:00.0000000. The .Kind property is used to decide whether that is UTC, local time, or "unspecified".
Most online converters, such as the one you linked to, are expecting a Unix Timestamp, where the value is based on an epoch of 1970-01-01T00:00:00.000Z. It is always UTC based. (The precision varies, both seconds and milliseconds are commonly used.)
If you want to get a milliseconds-based Unix Timestamp From .NET, instead of dividing you should use the built-in functions DateTimeOffset.FromUnixTimeMilliseconds and DateTimeOffset.ToUnixTimeMilliseconds. (There are also seconds-based versions of these functions.)
Assuming your input values are UTC-based:
DateTime dt = new DateTime(2020, 11, 1, 8, 11, 14, DateTimeKind.Utc);
DateTimeOffset dto = new DateTimeOffset(dt);
long timestamp = dto.ToUnixTimeMilliseconds();
// output: 1604218274000
DateTimeKind.Local will also work with this, assuming your values are indeed based on the computer's local time zone. DateTimeKind.Unspecified is a bit trickier, as you'll need to convert to a DateTimeOffset with a specific time zone using TimeZoneInfo first.
You could also construct the DateTimeOffset value directly, rather than go through DateTime at all.

Okay, so you start off dividing Ticks by TicksPerMillisecond (10,000)
As you can see, the number you generated is much larger than the current milliseconds:
63739786274788
1607363529803
The short answer is that Ticks are based off of 12:00:00 midnight January 1, 0001 and a your online calculator is based off of unix time, January 1, 1970. So that would explain why you're about 2,000 years off. If you subtracted the Ticks from a new DateTime(1970,1,1), then that would give you about the right number to satisfy the online calculator.
For more info, I would suggest reading through MS's docs on DateTime

Store and Retrieve DateTime to SQL as Integer

I've played a little with SQLite in the past, and I like it enough that I want to use it for a new project.
Step 1 is creating the database, and I need to create a DateStamp field where I place a time stamp on when an event occurred.
In the SQLite Documentation, the Date and Time Datatype is defined as follows:
1.2 Date and Time Datatype
SQLite does not have a storage class set aside for storing dates
and/or times. Instead, the built-in Date And Time Functions of SQLite
are capable of storing dates and times as TEXT, REAL, or INTEGER
values:
TEXT as ISO8601 strings ("YYYY-MM-DD HH:MM:SS.SSS").
REAL as Julian day numbers, the number of days since noon in Greenwich on November 24, 4714 B.C. according to the proleptic
Gregorian calendar.
INTEGER as Unix Time, the number of seconds since 1970-01-01 00:00:00 UTC.
Applications can chose to store dates and times in any of these
formats and freely convert between formats using the built-in date and
time functions.
I'd rather not save dates as text, and since the Windows DateTime object does not go back to November 24, 4714 B.C., I supposed I'm left with storing DateTime values as an INTEGER.
So, how do I store the DateTime as an Integer? Would I get the TimeSpan between base date and date I want, extract the number of days, and store that?
// is this a UTC date?
private static readonly DateTime utc1970_01_01 = new DateTime(1970, 1, 1);
public static double GetIntDate(DateTime dateTime) {
// FYI: subtracting dates in .NET returns a time span object
return (dateTime - nov24_4714bc).TotalSeconds;
}
Is that right? Is this what everyone else is doing that uses SQLite?
It also says that SQLite stores datetime in UTC time, so I need to convert again on top of that.
Surely someone has done this before. I would appreciate seeing tools someone has made already that handles these inputs. SQLite has some built in functions, but I don't really understand how to use them.
Solved:
Well poo.
Could it be as simple as this?
public static long ToFileTimeUtc(DateTime dateTime) {
return dateTime.ToFileTimeUtc();
}
public static DateTime FromFileTimeUtc(long fileTimeUtc) {
return DateTime.FromFileTimeUtc(fileTimeUtc);
}
Comments?
Can I not do that?

Whether or not you can use FileTime depends on whether anything but your app will ever be accessing the data. FileTime represents the number of 100-nanosecond intervals since January 1, 1601 (UTC).
As such, you will need to make sure the integer is an 8 byte integer in SQLLite in order to store the entire value.
As long as your app is the only app to deal with this data, and you always use FileTime, then there's no problem. If others will access this data, and they're capable of understanding FileTime, and they are aware that this is what it is, then there is also no problem.

Well poo.
Could it be as simple as this?
public static long ToFileTimeUtc(DateTime dateTime) {
return dateTime.ToFileTimeUtc();
}
public static DateTime FromFileTimeUtc(long fileTimeUtc) {
return DateTime.FromFileTimeUtc(fileTimeUtc);
}
Comments?
Can I not do that?

Compare date less than 3 months

I need to compare whether date is less than 3 months old.
I will get installation date:
DateTime installdate=DateTime.Parse("1/5/2012 8:12:14 PM");
if ((installdate<DateTime.Now.AddMonths(-3)))
{
// do something
}
Is this the best way to compare the dates?
Thanks.

A few things to think about:
"Is date x earlier than 3 months before today" isn't the same as "today is more than 3 months later than date x"; you'll need to make sure you have the exact semantics you want.
Consider what you want to do with the time component - are you interested in dates or dates and times? (Would you expect the condition evaluation to change based on the current time of day?)
Consider time zones: are you interested in "today in the system's current time zone" or some fixed time zone?
Depending on the source of the text data, you should possibly use DateTime.TryParse and you should possibly use DateTime.ParseExact or DateTime.TryParseExact, passing in the expected format (and culture)
Basically, there are various corner cases around date and time behaviour - you should explicitly think about all of these things (some of which are forced upon you if you use Noda Time instead of DateTime, btw :)
Regarding the first point, if the idea is that you get a trial period of three months from the installation date (or something similar), that suggests you should be adding three months to that instead.
I'd also change the variable name and get rid of the redundant parentheses, by the way:
DateTime installationDate = DateTime.Parse("1/5/2012 8:12:14 PM");
DateTime trialPeriodEnd = installationDate.AddMonths(3);
if (trialPeriodEnd > DateTime.Now)
{
// do something
}
Assuming you're storing the installation date yourself somewhere, I would try to store it in some form which is less ambiguous - possibly even storing just a "ticks" value instead of a string. But assuming you are storing it yourself, you shouldn't need to use TryParse - it makes sense to go "bang" if you can't parse the value. I'd use ParseExact, probably with a standard format specifier of "o" (round trip).

DateTime installdate ;
if (DateTime.TryParse("1/5/2012 8:12:14 PM", out installdate))
{
if ((installdate < DateTime.Now.AddMonths(-3))) { }
}
Tryparse is used so as to validate if the date passed in the parameter is valid or invalid

how to add current date time in bigint field

I need to add the current date time in a bigint field in a database... and then display from that only the date in format: october 1, 2009.
I am currently thinking of storing the value in string variable and then converting it to int...
String s = DateTime.Now.ToString();
i dont know what to do next..
please help

You could just store the number of ticks as your bigint value. Ticks represent the number of elapsed 1/10,000 of milliseconds since January 1, 0001.
DateTime.Now.Ticks;
This can always be converted back to a DateTime by using the constructor that accepts a long:
DateTime storedTime = new DateTime(ticksFromDatabase);
To format your date, just use any of the standard date format strings. A custom format string might work better actually, I just perused them and it doesn't look like there's a built in one for the format you want. This should work:
date1.ToString("MMMM d, yyyy", CultureInfo.CreateSpecificCulture("en-US"))

I'd use a smart date key, since it's easier to find that using SQL:
20090927235000
yyyyMMddhhmmss
This way, if you want to find anything that happened on a given day, you could do:
select * from tbl where datecol between 20090927000000 and 20090927240000
Thereby making data validation a lot easier, even if you are using an ORM.

Incomplete DateTime In C#

In C# if I want to parse a datetime, but some times I just have either a date and not a time component or no date but a time component, how would I do this? Usually when you leave out the time component, it automatically assumes that the time is 12:00AM. But I don't want this. If the time component is missing then I just want the DateTime to store a date only and the leave the time component off.

The value of a DateTime internally is just an UInt64 (ulong in C#) that stores the number of ticks since some date in the past, so whether you like it or not, the time component will always be there.

If you only need to display certain parts, just use any of the format strings (examples are for "en-us" culture):
DateTime.Now.ToString("d"); // 5/26/2009
DateTime.Now.ToString("t"); // 4:56 PM
The complete reference: http://msdn.microsoft.com/en-us/library/az4se3k1.aspx

It's not possible to have a DateTime without a time component. You could store a boolean flag along with it in a struct to store data about existence of that component. However, there's no way to use the automatic parsing routine to distinguish between a DateTime string with a time specified as 12:00 PM and a nonexistent one.

If it really bugs you you can always create a wrapper class that can hide the time portions of the datetime class.

No you will have the time component no matter what. The best you can do is access the Date property on your DateTime object if you really have to.
http://msdn.microsoft.com/en-us/library/system.datetime.date.aspx

DateTime by definition stores a date and a time such that it cannot just represent one of them without representing the other. If you only want the date (or only the time), parse out the information you need and discard the rest of it.

As mentioned before DateTime will always have a Date and a Time part of it if you only want a single part use the way described by the others
DateTime date = DateTime.Parse("2009-11-30);
date.Year; = 2009
date.Month; = 11
date.Day; = 30
date.Hour; = 0
and so on
The thing you must be aware is that all of these methods will only return an integer.
If you want to know all the possible ways to parse a string John Sheehan has put together a great Cheat Sheet wit all possible ways to parse and manipulate dates, and other strings for that matter.

You could have a class that stores a DateTime and determines if the time was ever set or if just the date was set and return values accordingly.

Use
DateTime date = new DateTime();
date = DateTime.Parse("1/1/2001");
to set the date, then use
date.ToShortDateString();
or
date.Year;
date.Month;
date.Day;
to get what you need. Hope that helps!

A DateTime object is always stores a date + a time, not just one. You can always choose to work only with the date part, i.e. only use properties like Year, Month, DayOfWeek. But underneath there will aways be some stored time.

It is very dangerous to assume that the date portion of a DateTime is necessarily the date you are expecting. As pointed-out, DateTime always includes and considers the time aspect, even when you don't see it.
This is a big problem when you have data stored in different time-zones (and particularly if knowledge of that offset is not also kept, because it is assumed that what is being stored is a Date, not a date-with-time).
You may store a birthdate as '01/01/2000 00:00:00' during Summer-Time, which then is stored in UCT as '31/12/1999 23:00:00'. When you then read that birth-date later, the date portion is now a day early.
Best to create your own type. Strange that Microsoft didn't think it worth having a Date type.