C# - Convert date to unix timestamp
I am trying to convert the date Saturday, 22. October 1932 00:00:00
to the unix timestamp -1173747600000
.
My code here:
DateTimeOffset dt2 = new DateTimeOffset(new DateTime(1932, 10, 22)).ToUniversalTime();
long a = dt2.ToUnixTimeMilliseconds();
I am getting the timestamp -1173751200000
. What are I doing wrong?
Epochconverter.com is calculating as expected the unix timestamp. See local time option and then Timestamp in milliseconds
c# datetime unix-timestamp
add a comment |
I am trying to convert the date Saturday, 22. October 1932 00:00:00
to the unix timestamp -1173747600000
.
My code here:
DateTimeOffset dt2 = new DateTimeOffset(new DateTime(1932, 10, 22)).ToUniversalTime();
long a = dt2.ToUnixTimeMilliseconds();
I am getting the timestamp -1173751200000
. What are I doing wrong?
Epochconverter.com is calculating as expected the unix timestamp. See local time option and then Timestamp in milliseconds
c# datetime unix-timestamp
1
From Remarks in DocumentationFor date and time values before 1970-01-01T00:00:00Z, this method returns a negative value.
– Make StackOverflow Good Again
Nov 21 '18 at 23:42
Yes, ok no problem. I am working with negative value.
– MrScf
Nov 21 '18 at 23:49
add a comment |
I am trying to convert the date Saturday, 22. October 1932 00:00:00
to the unix timestamp -1173747600000
.
My code here:
DateTimeOffset dt2 = new DateTimeOffset(new DateTime(1932, 10, 22)).ToUniversalTime();
long a = dt2.ToUnixTimeMilliseconds();
I am getting the timestamp -1173751200000
. What are I doing wrong?
Epochconverter.com is calculating as expected the unix timestamp. See local time option and then Timestamp in milliseconds
c# datetime unix-timestamp
I am trying to convert the date Saturday, 22. October 1932 00:00:00
to the unix timestamp -1173747600000
.
My code here:
DateTimeOffset dt2 = new DateTimeOffset(new DateTime(1932, 10, 22)).ToUniversalTime();
long a = dt2.ToUnixTimeMilliseconds();
I am getting the timestamp -1173751200000
. What are I doing wrong?
Epochconverter.com is calculating as expected the unix timestamp. See local time option and then Timestamp in milliseconds
c# datetime unix-timestamp
c# datetime unix-timestamp
asked Nov 21 '18 at 23:39
MrScfMrScf
6042620
6042620
1
From Remarks in DocumentationFor date and time values before 1970-01-01T00:00:00Z, this method returns a negative value.
– Make StackOverflow Good Again
Nov 21 '18 at 23:42
Yes, ok no problem. I am working with negative value.
– MrScf
Nov 21 '18 at 23:49
add a comment |
1
From Remarks in DocumentationFor date and time values before 1970-01-01T00:00:00Z, this method returns a negative value.
– Make StackOverflow Good Again
Nov 21 '18 at 23:42
Yes, ok no problem. I am working with negative value.
– MrScf
Nov 21 '18 at 23:49
1
1
From Remarks in Documentation
For date and time values before 1970-01-01T00:00:00Z, this method returns a negative value.
– Make StackOverflow Good Again
Nov 21 '18 at 23:42
From Remarks in Documentation
For date and time values before 1970-01-01T00:00:00Z, this method returns a negative value.
– Make StackOverflow Good Again
Nov 21 '18 at 23:42
Yes, ok no problem. I am working with negative value.
– MrScf
Nov 21 '18 at 23:49
Yes, ok no problem. I am working with negative value.
– MrScf
Nov 21 '18 at 23:49
add a comment |
3 Answers
3
active
oldest
votes
The first clue is the difference in the timestamps: they're 3600 seconds apart, or in other words one hour. My guess is that there's a daylight savings issue coming in to play.
You can see that this is being applied by DateTimeOffset by looking at the properties of the object. Using it in Powershell:
$t = [datetime]::Parse("1932-10-22")
new-object system.datetimeoffset($t)
gives output:
DateTime : 22/10/1932 00:00:00
UtcDateTime : 21/10/1932 23:00:00
LocalDateTime : 22/10/1932 00:00:00
Date : 22/10/1932 00:00:00
Day : 22
DayOfWeek : Saturday
DayOfYear : 296
Hour : 0
Millisecond : 0
Minute : 0
Month : 10
Offset : 01:00:00
Second : 0
Ticks : 609618528000000000
UtcTicks : 609618492000000000
TimeOfDay : 00:00:00
Year : 1932
DateTimeOffset.ToUniversalTimeMilliseconds()
returns the unix-time from the UTC value of the datetime.
So you need to create the DateTimeOffset with the UTC timezone instead, so (again with PS, but it's trivial to convert to C#)
$t = [datetime]::Parse("1932-10-22")^C
$ofs = new-object System.Timespan(0)
new-object system.datetimeoffset($t, $ofs)
Gives:
DateTime : 22/10/1932 00:00:00
UtcDateTime : 22/10/1932 00:00:00
LocalDateTime : 22/10/1932 01:00:00
Date : 22/10/1932 00:00:00
Day : 22
DayOfWeek : Saturday
DayOfYear : 296
Hour : 0
Millisecond : 0
Minute : 0
Month : 10
Offset : 00:00:00
Second : 0
Ticks : 609618528000000000
UtcTicks : 609618528000000000
TimeOfDay : 00:00:00
Year : 1932
Now this gives an millisecond epoch timestamp of -1173744000000, which is different to the value you're expecting. I've checked a couple of sources, including epochconvertor.com and this does appear to be the correct time. The timestamp you've provided, -1173747600000, is 21 Oct 1932 at 23:00:00.
add a comment |
You're forgetting the time zone. The only time zone where 22 October 1932 00:00
equals -1173747600000
is UTC-01:00
There isn't any way in .NET (that I can find) to create a DateTime
in a time zone other than local or UTC, so you have to just subtract an hour (from UTC), which takes you to 21 October 1932 23:00 UTC
:
var date = new DateTime(1932, 10, 21, 23, 0, 0, DateTimeKind.Utc);
var dt2 = new DateTimeOffset(date).ToUniversalTime();
long a = dt2.ToUnixTimeMilliseconds();
That results in -1173747600000
.
add a comment |
UNIX timestamp is the number of seconds that passed since 1. 1. 1970. That is why you get a negative number for a date that preceds it.
Yes, I know. I am getting negative number because the date is before 1.1.1970. But if I get -1173751200000 instead -1173747600000, it works. Why epochconverter interprets right the negative duration?
– MrScf
Nov 21 '18 at 23:48
add a comment |
Your Answer
StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53421969%2fc-sharp-convert-date-to-unix-timestamp%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
3 Answers
3
active
oldest
votes
3 Answers
3
active
oldest
votes
active
oldest
votes
active
oldest
votes
The first clue is the difference in the timestamps: they're 3600 seconds apart, or in other words one hour. My guess is that there's a daylight savings issue coming in to play.
You can see that this is being applied by DateTimeOffset by looking at the properties of the object. Using it in Powershell:
$t = [datetime]::Parse("1932-10-22")
new-object system.datetimeoffset($t)
gives output:
DateTime : 22/10/1932 00:00:00
UtcDateTime : 21/10/1932 23:00:00
LocalDateTime : 22/10/1932 00:00:00
Date : 22/10/1932 00:00:00
Day : 22
DayOfWeek : Saturday
DayOfYear : 296
Hour : 0
Millisecond : 0
Minute : 0
Month : 10
Offset : 01:00:00
Second : 0
Ticks : 609618528000000000
UtcTicks : 609618492000000000
TimeOfDay : 00:00:00
Year : 1932
DateTimeOffset.ToUniversalTimeMilliseconds()
returns the unix-time from the UTC value of the datetime.
So you need to create the DateTimeOffset with the UTC timezone instead, so (again with PS, but it's trivial to convert to C#)
$t = [datetime]::Parse("1932-10-22")^C
$ofs = new-object System.Timespan(0)
new-object system.datetimeoffset($t, $ofs)
Gives:
DateTime : 22/10/1932 00:00:00
UtcDateTime : 22/10/1932 00:00:00
LocalDateTime : 22/10/1932 01:00:00
Date : 22/10/1932 00:00:00
Day : 22
DayOfWeek : Saturday
DayOfYear : 296
Hour : 0
Millisecond : 0
Minute : 0
Month : 10
Offset : 00:00:00
Second : 0
Ticks : 609618528000000000
UtcTicks : 609618528000000000
TimeOfDay : 00:00:00
Year : 1932
Now this gives an millisecond epoch timestamp of -1173744000000, which is different to the value you're expecting. I've checked a couple of sources, including epochconvertor.com and this does appear to be the correct time. The timestamp you've provided, -1173747600000, is 21 Oct 1932 at 23:00:00.
add a comment |
The first clue is the difference in the timestamps: they're 3600 seconds apart, or in other words one hour. My guess is that there's a daylight savings issue coming in to play.
You can see that this is being applied by DateTimeOffset by looking at the properties of the object. Using it in Powershell:
$t = [datetime]::Parse("1932-10-22")
new-object system.datetimeoffset($t)
gives output:
DateTime : 22/10/1932 00:00:00
UtcDateTime : 21/10/1932 23:00:00
LocalDateTime : 22/10/1932 00:00:00
Date : 22/10/1932 00:00:00
Day : 22
DayOfWeek : Saturday
DayOfYear : 296
Hour : 0
Millisecond : 0
Minute : 0
Month : 10
Offset : 01:00:00
Second : 0
Ticks : 609618528000000000
UtcTicks : 609618492000000000
TimeOfDay : 00:00:00
Year : 1932
DateTimeOffset.ToUniversalTimeMilliseconds()
returns the unix-time from the UTC value of the datetime.
So you need to create the DateTimeOffset with the UTC timezone instead, so (again with PS, but it's trivial to convert to C#)
$t = [datetime]::Parse("1932-10-22")^C
$ofs = new-object System.Timespan(0)
new-object system.datetimeoffset($t, $ofs)
Gives:
DateTime : 22/10/1932 00:00:00
UtcDateTime : 22/10/1932 00:00:00
LocalDateTime : 22/10/1932 01:00:00
Date : 22/10/1932 00:00:00
Day : 22
DayOfWeek : Saturday
DayOfYear : 296
Hour : 0
Millisecond : 0
Minute : 0
Month : 10
Offset : 00:00:00
Second : 0
Ticks : 609618528000000000
UtcTicks : 609618528000000000
TimeOfDay : 00:00:00
Year : 1932
Now this gives an millisecond epoch timestamp of -1173744000000, which is different to the value you're expecting. I've checked a couple of sources, including epochconvertor.com and this does appear to be the correct time. The timestamp you've provided, -1173747600000, is 21 Oct 1932 at 23:00:00.
add a comment |
The first clue is the difference in the timestamps: they're 3600 seconds apart, or in other words one hour. My guess is that there's a daylight savings issue coming in to play.
You can see that this is being applied by DateTimeOffset by looking at the properties of the object. Using it in Powershell:
$t = [datetime]::Parse("1932-10-22")
new-object system.datetimeoffset($t)
gives output:
DateTime : 22/10/1932 00:00:00
UtcDateTime : 21/10/1932 23:00:00
LocalDateTime : 22/10/1932 00:00:00
Date : 22/10/1932 00:00:00
Day : 22
DayOfWeek : Saturday
DayOfYear : 296
Hour : 0
Millisecond : 0
Minute : 0
Month : 10
Offset : 01:00:00
Second : 0
Ticks : 609618528000000000
UtcTicks : 609618492000000000
TimeOfDay : 00:00:00
Year : 1932
DateTimeOffset.ToUniversalTimeMilliseconds()
returns the unix-time from the UTC value of the datetime.
So you need to create the DateTimeOffset with the UTC timezone instead, so (again with PS, but it's trivial to convert to C#)
$t = [datetime]::Parse("1932-10-22")^C
$ofs = new-object System.Timespan(0)
new-object system.datetimeoffset($t, $ofs)
Gives:
DateTime : 22/10/1932 00:00:00
UtcDateTime : 22/10/1932 00:00:00
LocalDateTime : 22/10/1932 01:00:00
Date : 22/10/1932 00:00:00
Day : 22
DayOfWeek : Saturday
DayOfYear : 296
Hour : 0
Millisecond : 0
Minute : 0
Month : 10
Offset : 00:00:00
Second : 0
Ticks : 609618528000000000
UtcTicks : 609618528000000000
TimeOfDay : 00:00:00
Year : 1932
Now this gives an millisecond epoch timestamp of -1173744000000, which is different to the value you're expecting. I've checked a couple of sources, including epochconvertor.com and this does appear to be the correct time. The timestamp you've provided, -1173747600000, is 21 Oct 1932 at 23:00:00.
The first clue is the difference in the timestamps: they're 3600 seconds apart, or in other words one hour. My guess is that there's a daylight savings issue coming in to play.
You can see that this is being applied by DateTimeOffset by looking at the properties of the object. Using it in Powershell:
$t = [datetime]::Parse("1932-10-22")
new-object system.datetimeoffset($t)
gives output:
DateTime : 22/10/1932 00:00:00
UtcDateTime : 21/10/1932 23:00:00
LocalDateTime : 22/10/1932 00:00:00
Date : 22/10/1932 00:00:00
Day : 22
DayOfWeek : Saturday
DayOfYear : 296
Hour : 0
Millisecond : 0
Minute : 0
Month : 10
Offset : 01:00:00
Second : 0
Ticks : 609618528000000000
UtcTicks : 609618492000000000
TimeOfDay : 00:00:00
Year : 1932
DateTimeOffset.ToUniversalTimeMilliseconds()
returns the unix-time from the UTC value of the datetime.
So you need to create the DateTimeOffset with the UTC timezone instead, so (again with PS, but it's trivial to convert to C#)
$t = [datetime]::Parse("1932-10-22")^C
$ofs = new-object System.Timespan(0)
new-object system.datetimeoffset($t, $ofs)
Gives:
DateTime : 22/10/1932 00:00:00
UtcDateTime : 22/10/1932 00:00:00
LocalDateTime : 22/10/1932 01:00:00
Date : 22/10/1932 00:00:00
Day : 22
DayOfWeek : Saturday
DayOfYear : 296
Hour : 0
Millisecond : 0
Minute : 0
Month : 10
Offset : 00:00:00
Second : 0
Ticks : 609618528000000000
UtcTicks : 609618528000000000
TimeOfDay : 00:00:00
Year : 1932
Now this gives an millisecond epoch timestamp of -1173744000000, which is different to the value you're expecting. I've checked a couple of sources, including epochconvertor.com and this does appear to be the correct time. The timestamp you've provided, -1173747600000, is 21 Oct 1932 at 23:00:00.
answered Nov 22 '18 at 0:17
Chris JChris J
24.3k45294
24.3k45294
add a comment |
add a comment |
You're forgetting the time zone. The only time zone where 22 October 1932 00:00
equals -1173747600000
is UTC-01:00
There isn't any way in .NET (that I can find) to create a DateTime
in a time zone other than local or UTC, so you have to just subtract an hour (from UTC), which takes you to 21 October 1932 23:00 UTC
:
var date = new DateTime(1932, 10, 21, 23, 0, 0, DateTimeKind.Utc);
var dt2 = new DateTimeOffset(date).ToUniversalTime();
long a = dt2.ToUnixTimeMilliseconds();
That results in -1173747600000
.
add a comment |
You're forgetting the time zone. The only time zone where 22 October 1932 00:00
equals -1173747600000
is UTC-01:00
There isn't any way in .NET (that I can find) to create a DateTime
in a time zone other than local or UTC, so you have to just subtract an hour (from UTC), which takes you to 21 October 1932 23:00 UTC
:
var date = new DateTime(1932, 10, 21, 23, 0, 0, DateTimeKind.Utc);
var dt2 = new DateTimeOffset(date).ToUniversalTime();
long a = dt2.ToUnixTimeMilliseconds();
That results in -1173747600000
.
add a comment |
You're forgetting the time zone. The only time zone where 22 October 1932 00:00
equals -1173747600000
is UTC-01:00
There isn't any way in .NET (that I can find) to create a DateTime
in a time zone other than local or UTC, so you have to just subtract an hour (from UTC), which takes you to 21 October 1932 23:00 UTC
:
var date = new DateTime(1932, 10, 21, 23, 0, 0, DateTimeKind.Utc);
var dt2 = new DateTimeOffset(date).ToUniversalTime();
long a = dt2.ToUnixTimeMilliseconds();
That results in -1173747600000
.
You're forgetting the time zone. The only time zone where 22 October 1932 00:00
equals -1173747600000
is UTC-01:00
There isn't any way in .NET (that I can find) to create a DateTime
in a time zone other than local or UTC, so you have to just subtract an hour (from UTC), which takes you to 21 October 1932 23:00 UTC
:
var date = new DateTime(1932, 10, 21, 23, 0, 0, DateTimeKind.Utc);
var dt2 = new DateTimeOffset(date).ToUniversalTime();
long a = dt2.ToUnixTimeMilliseconds();
That results in -1173747600000
.
edited Nov 22 '18 at 20:36
answered Nov 22 '18 at 1:22
Gabriel LuciGabriel Luci
11.5k11525
11.5k11525
add a comment |
add a comment |
UNIX timestamp is the number of seconds that passed since 1. 1. 1970. That is why you get a negative number for a date that preceds it.
Yes, I know. I am getting negative number because the date is before 1.1.1970. But if I get -1173751200000 instead -1173747600000, it works. Why epochconverter interprets right the negative duration?
– MrScf
Nov 21 '18 at 23:48
add a comment |
UNIX timestamp is the number of seconds that passed since 1. 1. 1970. That is why you get a negative number for a date that preceds it.
Yes, I know. I am getting negative number because the date is before 1.1.1970. But if I get -1173751200000 instead -1173747600000, it works. Why epochconverter interprets right the negative duration?
– MrScf
Nov 21 '18 at 23:48
add a comment |
UNIX timestamp is the number of seconds that passed since 1. 1. 1970. That is why you get a negative number for a date that preceds it.
UNIX timestamp is the number of seconds that passed since 1. 1. 1970. That is why you get a negative number for a date that preceds it.
answered Nov 21 '18 at 23:42
Martin HeraleckýMartin Heralecký
3,17421135
3,17421135
Yes, I know. I am getting negative number because the date is before 1.1.1970. But if I get -1173751200000 instead -1173747600000, it works. Why epochconverter interprets right the negative duration?
– MrScf
Nov 21 '18 at 23:48
add a comment |
Yes, I know. I am getting negative number because the date is before 1.1.1970. But if I get -1173751200000 instead -1173747600000, it works. Why epochconverter interprets right the negative duration?
– MrScf
Nov 21 '18 at 23:48
Yes, I know. I am getting negative number because the date is before 1.1.1970. But if I get -1173751200000 instead -1173747600000, it works. Why epochconverter interprets right the negative duration?
– MrScf
Nov 21 '18 at 23:48
Yes, I know. I am getting negative number because the date is before 1.1.1970. But if I get -1173751200000 instead -1173747600000, it works. Why epochconverter interprets right the negative duration?
– MrScf
Nov 21 '18 at 23:48
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53421969%2fc-sharp-convert-date-to-unix-timestamp%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
1
From Remarks in Documentation
For date and time values before 1970-01-01T00:00:00Z, this method returns a negative value.
– Make StackOverflow Good Again
Nov 21 '18 at 23:42
Yes, ok no problem. I am working with negative value.
– MrScf
Nov 21 '18 at 23:49