C# - Convert date to unix timestamp












0















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










share|improve this question


















  • 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
















0















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










share|improve this question


















  • 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














0












0








0








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










share|improve this question














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






share|improve this question













share|improve this question











share|improve this question




share|improve this question










asked Nov 21 '18 at 23:39









MrScfMrScf

6042620




6042620








  • 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














  • 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








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












3 Answers
3






active

oldest

votes


















1














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.






share|improve this answer































    1














    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.






    share|improve this answer

































      0














      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.






      share|improve this answer
























      • 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












      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
      });


      }
      });














      draft saved

      draft discarded


















      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









      1














      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.






      share|improve this answer




























        1














        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.






        share|improve this answer


























          1












          1








          1







          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.






          share|improve this answer













          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.







          share|improve this answer












          share|improve this answer



          share|improve this answer










          answered Nov 22 '18 at 0:17









          Chris JChris J

          24.3k45294




          24.3k45294

























              1














              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.






              share|improve this answer






























                1














                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.






                share|improve this answer




























                  1












                  1








                  1







                  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.






                  share|improve this answer















                  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.







                  share|improve this answer














                  share|improve this answer



                  share|improve this answer








                  edited Nov 22 '18 at 20:36

























                  answered Nov 22 '18 at 1:22









                  Gabriel LuciGabriel Luci

                  11.5k11525




                  11.5k11525























                      0














                      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.






                      share|improve this answer
























                      • 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
















                      0














                      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.






                      share|improve this answer
























                      • 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














                      0












                      0








                      0







                      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.






                      share|improve this answer













                      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.







                      share|improve this answer












                      share|improve this answer



                      share|improve this answer










                      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



















                      • 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


















                      draft saved

                      draft discarded




















































                      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.




                      draft saved


                      draft discarded














                      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





















































                      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







                      Popular posts from this blog

                      How to change which sound is reproduced for terminal bell?

                      Title Spacing in Bjornstrup Chapter, Removing Chapter Number From Contents

                      Can I use Tabulator js library in my java Spring + Thymeleaf project?