Possible bug in as.POSIXct












2















I am working with time data, and I covert it to POSIXct class (read as strings). When I do this it work with all my data but no with one specific string. What I do is in essences:



Time1 <- '1900-04-01' # First Year then Month then Day
Time1_convert <- as.POSIXct( Time1, format='%Y-%m-%d')


I do this vectorized and all my data is well converted. But with the date 1920-05-01



Time1 <- '1920-05-01' 
Time1_convert <- as.POSIXct( Time1, format='%Y-%m-%d' )


This return NA. I have no idea why this happens. If I add to the as.POSIXct function tz = 'GMT'; the time is well convert for all values. What I do not understand is why this happen and why this happen with this specific value when I have tried with more than 1500 different times values.



I add an image of the output:
Output in RStudio



More code added:



for( m in c(01,02,03,04,05,06,07,08,09,10,11,12)){ 
print(as.POSIXct(paste0('1920-',m,'-01'),format='%Y-%m-%d'))
}


and the output is:



[1] "1920-01-01 CMT"
[1] "1920-02-01 CMT"
[1] "1920-03-01 CMT"
[1] "1920-04-01 CMT"
[1] NA
[1] "1920-06-01 -04"
[1] "1920-07-01 -04"
[1] "1920-08-01 -04"
[1] "1920-09-01 -04"
[1] "1920-10-01 -04"
[1] "1920-11-01 -04"
[1] "1920-12-01 -04"


Output of sessionInfo():



R version 3.3.3 (2017-03-06)
Platform: x86_64-pc-linux-gnu (64-bit)
Running under: Debian GNU/Linux 9 (stretch)

locale:
[1] LC_CTYPE=es_AR.UTF-8 LC_NUMERIC=C
[3] LC_TIME=es_AR.UTF-8 LC_COLLATE=es_AR.UTF-8
[5] LC_MONETARY=es_AR.UTF-8 LC_MESSAGES=es_AR.UTF-8
[7] LC_PAPER=es_AR.UTF-8 LC_NAME=C
[9] LC_ADDRESS=C LC_TELEPHONE=C
[11] LC_MEASUREMENT=es_AR.UTF-8 LC_IDENTIFICATION=C

attached base packages:
[1] stats graphics grDevices utils datasets methods
[7] base

loaded via a namespace (and not attached):
[1] tools_3.3.3









share|improve this question




















  • 3





    Works fine for me too. May be a locale issue.

    – iod
    Nov 15 '18 at 18:57






  • 1





    make sure it actually 1920-05-01, there might be leading or trailing spaces

    – Jrakru56
    Nov 15 '18 at 18:59






  • 2





    Can you share the output of sessionInfo()?

    – dmca
    Nov 15 '18 at 20:20






  • 1





    I suspect Argentina had a time adjustment then. From here: opensource.apple.com/source/system_cmds/system_cmds-336.10/… # From Paul Eggert (2002-01-22): # <a href="spicasc.net/horvera.html"> # Hora de verano para la Republica Argentina (2000-10-01) # </a> says that standard time in Argentina from 1894-10-31 # to 1920-05-01 was -4:16:48.25. Go with this more-precise value # over Shanks.

    – Jon Spring
    Nov 15 '18 at 23:52








  • 3





    Yes, see more here: statoids.com/tar.html That was a date when Argentina changed its time zone.

    – Jon Spring
    Nov 15 '18 at 23:53


















2















I am working with time data, and I covert it to POSIXct class (read as strings). When I do this it work with all my data but no with one specific string. What I do is in essences:



Time1 <- '1900-04-01' # First Year then Month then Day
Time1_convert <- as.POSIXct( Time1, format='%Y-%m-%d')


I do this vectorized and all my data is well converted. But with the date 1920-05-01



Time1 <- '1920-05-01' 
Time1_convert <- as.POSIXct( Time1, format='%Y-%m-%d' )


This return NA. I have no idea why this happens. If I add to the as.POSIXct function tz = 'GMT'; the time is well convert for all values. What I do not understand is why this happen and why this happen with this specific value when I have tried with more than 1500 different times values.



I add an image of the output:
Output in RStudio



More code added:



for( m in c(01,02,03,04,05,06,07,08,09,10,11,12)){ 
print(as.POSIXct(paste0('1920-',m,'-01'),format='%Y-%m-%d'))
}


and the output is:



[1] "1920-01-01 CMT"
[1] "1920-02-01 CMT"
[1] "1920-03-01 CMT"
[1] "1920-04-01 CMT"
[1] NA
[1] "1920-06-01 -04"
[1] "1920-07-01 -04"
[1] "1920-08-01 -04"
[1] "1920-09-01 -04"
[1] "1920-10-01 -04"
[1] "1920-11-01 -04"
[1] "1920-12-01 -04"


Output of sessionInfo():



R version 3.3.3 (2017-03-06)
Platform: x86_64-pc-linux-gnu (64-bit)
Running under: Debian GNU/Linux 9 (stretch)

locale:
[1] LC_CTYPE=es_AR.UTF-8 LC_NUMERIC=C
[3] LC_TIME=es_AR.UTF-8 LC_COLLATE=es_AR.UTF-8
[5] LC_MONETARY=es_AR.UTF-8 LC_MESSAGES=es_AR.UTF-8
[7] LC_PAPER=es_AR.UTF-8 LC_NAME=C
[9] LC_ADDRESS=C LC_TELEPHONE=C
[11] LC_MEASUREMENT=es_AR.UTF-8 LC_IDENTIFICATION=C

attached base packages:
[1] stats graphics grDevices utils datasets methods
[7] base

loaded via a namespace (and not attached):
[1] tools_3.3.3









share|improve this question




















  • 3





    Works fine for me too. May be a locale issue.

    – iod
    Nov 15 '18 at 18:57






  • 1





    make sure it actually 1920-05-01, there might be leading or trailing spaces

    – Jrakru56
    Nov 15 '18 at 18:59






  • 2





    Can you share the output of sessionInfo()?

    – dmca
    Nov 15 '18 at 20:20






  • 1





    I suspect Argentina had a time adjustment then. From here: opensource.apple.com/source/system_cmds/system_cmds-336.10/… # From Paul Eggert (2002-01-22): # <a href="spicasc.net/horvera.html"> # Hora de verano para la Republica Argentina (2000-10-01) # </a> says that standard time in Argentina from 1894-10-31 # to 1920-05-01 was -4:16:48.25. Go with this more-precise value # over Shanks.

    – Jon Spring
    Nov 15 '18 at 23:52








  • 3





    Yes, see more here: statoids.com/tar.html That was a date when Argentina changed its time zone.

    – Jon Spring
    Nov 15 '18 at 23:53
















2












2








2








I am working with time data, and I covert it to POSIXct class (read as strings). When I do this it work with all my data but no with one specific string. What I do is in essences:



Time1 <- '1900-04-01' # First Year then Month then Day
Time1_convert <- as.POSIXct( Time1, format='%Y-%m-%d')


I do this vectorized and all my data is well converted. But with the date 1920-05-01



Time1 <- '1920-05-01' 
Time1_convert <- as.POSIXct( Time1, format='%Y-%m-%d' )


This return NA. I have no idea why this happens. If I add to the as.POSIXct function tz = 'GMT'; the time is well convert for all values. What I do not understand is why this happen and why this happen with this specific value when I have tried with more than 1500 different times values.



I add an image of the output:
Output in RStudio



More code added:



for( m in c(01,02,03,04,05,06,07,08,09,10,11,12)){ 
print(as.POSIXct(paste0('1920-',m,'-01'),format='%Y-%m-%d'))
}


and the output is:



[1] "1920-01-01 CMT"
[1] "1920-02-01 CMT"
[1] "1920-03-01 CMT"
[1] "1920-04-01 CMT"
[1] NA
[1] "1920-06-01 -04"
[1] "1920-07-01 -04"
[1] "1920-08-01 -04"
[1] "1920-09-01 -04"
[1] "1920-10-01 -04"
[1] "1920-11-01 -04"
[1] "1920-12-01 -04"


Output of sessionInfo():



R version 3.3.3 (2017-03-06)
Platform: x86_64-pc-linux-gnu (64-bit)
Running under: Debian GNU/Linux 9 (stretch)

locale:
[1] LC_CTYPE=es_AR.UTF-8 LC_NUMERIC=C
[3] LC_TIME=es_AR.UTF-8 LC_COLLATE=es_AR.UTF-8
[5] LC_MONETARY=es_AR.UTF-8 LC_MESSAGES=es_AR.UTF-8
[7] LC_PAPER=es_AR.UTF-8 LC_NAME=C
[9] LC_ADDRESS=C LC_TELEPHONE=C
[11] LC_MEASUREMENT=es_AR.UTF-8 LC_IDENTIFICATION=C

attached base packages:
[1] stats graphics grDevices utils datasets methods
[7] base

loaded via a namespace (and not attached):
[1] tools_3.3.3









share|improve this question
















I am working with time data, and I covert it to POSIXct class (read as strings). When I do this it work with all my data but no with one specific string. What I do is in essences:



Time1 <- '1900-04-01' # First Year then Month then Day
Time1_convert <- as.POSIXct( Time1, format='%Y-%m-%d')


I do this vectorized and all my data is well converted. But with the date 1920-05-01



Time1 <- '1920-05-01' 
Time1_convert <- as.POSIXct( Time1, format='%Y-%m-%d' )


This return NA. I have no idea why this happens. If I add to the as.POSIXct function tz = 'GMT'; the time is well convert for all values. What I do not understand is why this happen and why this happen with this specific value when I have tried with more than 1500 different times values.



I add an image of the output:
Output in RStudio



More code added:



for( m in c(01,02,03,04,05,06,07,08,09,10,11,12)){ 
print(as.POSIXct(paste0('1920-',m,'-01'),format='%Y-%m-%d'))
}


and the output is:



[1] "1920-01-01 CMT"
[1] "1920-02-01 CMT"
[1] "1920-03-01 CMT"
[1] "1920-04-01 CMT"
[1] NA
[1] "1920-06-01 -04"
[1] "1920-07-01 -04"
[1] "1920-08-01 -04"
[1] "1920-09-01 -04"
[1] "1920-10-01 -04"
[1] "1920-11-01 -04"
[1] "1920-12-01 -04"


Output of sessionInfo():



R version 3.3.3 (2017-03-06)
Platform: x86_64-pc-linux-gnu (64-bit)
Running under: Debian GNU/Linux 9 (stretch)

locale:
[1] LC_CTYPE=es_AR.UTF-8 LC_NUMERIC=C
[3] LC_TIME=es_AR.UTF-8 LC_COLLATE=es_AR.UTF-8
[5] LC_MONETARY=es_AR.UTF-8 LC_MESSAGES=es_AR.UTF-8
[7] LC_PAPER=es_AR.UTF-8 LC_NAME=C
[9] LC_ADDRESS=C LC_TELEPHONE=C
[11] LC_MEASUREMENT=es_AR.UTF-8 LC_IDENTIFICATION=C

attached base packages:
[1] stats graphics grDevices utils datasets methods
[7] base

loaded via a namespace (and not attached):
[1] tools_3.3.3






r time posixct






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited Nov 15 '18 at 20:33







Santiago I. Hurtado

















asked Nov 15 '18 at 18:51









Santiago I. HurtadoSantiago I. Hurtado

125210




125210








  • 3





    Works fine for me too. May be a locale issue.

    – iod
    Nov 15 '18 at 18:57






  • 1





    make sure it actually 1920-05-01, there might be leading or trailing spaces

    – Jrakru56
    Nov 15 '18 at 18:59






  • 2





    Can you share the output of sessionInfo()?

    – dmca
    Nov 15 '18 at 20:20






  • 1





    I suspect Argentina had a time adjustment then. From here: opensource.apple.com/source/system_cmds/system_cmds-336.10/… # From Paul Eggert (2002-01-22): # <a href="spicasc.net/horvera.html"> # Hora de verano para la Republica Argentina (2000-10-01) # </a> says that standard time in Argentina from 1894-10-31 # to 1920-05-01 was -4:16:48.25. Go with this more-precise value # over Shanks.

    – Jon Spring
    Nov 15 '18 at 23:52








  • 3





    Yes, see more here: statoids.com/tar.html That was a date when Argentina changed its time zone.

    – Jon Spring
    Nov 15 '18 at 23:53
















  • 3





    Works fine for me too. May be a locale issue.

    – iod
    Nov 15 '18 at 18:57






  • 1





    make sure it actually 1920-05-01, there might be leading or trailing spaces

    – Jrakru56
    Nov 15 '18 at 18:59






  • 2





    Can you share the output of sessionInfo()?

    – dmca
    Nov 15 '18 at 20:20






  • 1





    I suspect Argentina had a time adjustment then. From here: opensource.apple.com/source/system_cmds/system_cmds-336.10/… # From Paul Eggert (2002-01-22): # <a href="spicasc.net/horvera.html"> # Hora de verano para la Republica Argentina (2000-10-01) # </a> says that standard time in Argentina from 1894-10-31 # to 1920-05-01 was -4:16:48.25. Go with this more-precise value # over Shanks.

    – Jon Spring
    Nov 15 '18 at 23:52








  • 3





    Yes, see more here: statoids.com/tar.html That was a date when Argentina changed its time zone.

    – Jon Spring
    Nov 15 '18 at 23:53










3




3





Works fine for me too. May be a locale issue.

– iod
Nov 15 '18 at 18:57





Works fine for me too. May be a locale issue.

– iod
Nov 15 '18 at 18:57




1




1





make sure it actually 1920-05-01, there might be leading or trailing spaces

– Jrakru56
Nov 15 '18 at 18:59





make sure it actually 1920-05-01, there might be leading or trailing spaces

– Jrakru56
Nov 15 '18 at 18:59




2




2





Can you share the output of sessionInfo()?

– dmca
Nov 15 '18 at 20:20





Can you share the output of sessionInfo()?

– dmca
Nov 15 '18 at 20:20




1




1





I suspect Argentina had a time adjustment then. From here: opensource.apple.com/source/system_cmds/system_cmds-336.10/… # From Paul Eggert (2002-01-22): # <a href="spicasc.net/horvera.html"> # Hora de verano para la Republica Argentina (2000-10-01) # </a> says that standard time in Argentina from 1894-10-31 # to 1920-05-01 was -4:16:48.25. Go with this more-precise value # over Shanks.

– Jon Spring
Nov 15 '18 at 23:52







I suspect Argentina had a time adjustment then. From here: opensource.apple.com/source/system_cmds/system_cmds-336.10/… # From Paul Eggert (2002-01-22): # <a href="spicasc.net/horvera.html"> # Hora de verano para la Republica Argentina (2000-10-01) # </a> says that standard time in Argentina from 1894-10-31 # to 1920-05-01 was -4:16:48.25. Go with this more-precise value # over Shanks.

– Jon Spring
Nov 15 '18 at 23:52






3




3





Yes, see more here: statoids.com/tar.html That was a date when Argentina changed its time zone.

– Jon Spring
Nov 15 '18 at 23:53







Yes, see more here: statoids.com/tar.html That was a date when Argentina changed its time zone.

– Jon Spring
Nov 15 '18 at 23:53














1 Answer
1






active

oldest

votes


















2














Your local settings appear to be based in Argentina. As it happens, Argentina reset their time zone on that date from UTC-4:16:48 to UTC-4. I think this means that there wasn't a midnight in Argentina on May 5, 1920. When you convert that string to POSIXct, it interprets it at midnight that day in your local time zone, which by coincidence is a time that did not exist in Argentina. (This explains why it was not reproducible for others who tried the same code.)



http://www.statoids.com/tar.html




Locations in Argentina observed Local Mean Time until 1894-10-31 00:00
(as measured after the transition). At that moment, the entire country
synchronized on Córdoba's Local Mean Time, which was UTC-4:16:48. The
next transition occurred at 1920-05-01 00:00, when clocks were set
ahead sixteen minutes and forty-eight seconds to be an even UTC-4.
Argentina remained unified on UTC-4 until its first daylight saving
time was inaugurated in 1931.




If you need a POSIXct object, you might consider:



a) specifying a different time zone where midnight existed on that day.



as.POSIXct("1920-05-01", tz = "UTC") 
# Or perhaps other nearby time zones didn't have that specific problem?


b) Storing the time in components, including one for date, and one for time within the day. e.g. time = hour(Time1) + minute(Time1)/60. It's a little unwieldy but it might be possible to perform the date / time calcs you need.






share|improve this answer

























    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%2f53326138%2fpossible-bug-in-as-posixct%23new-answer', 'question_page');
    }
    );

    Post as a guest















    Required, but never shown

























    1 Answer
    1






    active

    oldest

    votes








    1 Answer
    1






    active

    oldest

    votes









    active

    oldest

    votes






    active

    oldest

    votes









    2














    Your local settings appear to be based in Argentina. As it happens, Argentina reset their time zone on that date from UTC-4:16:48 to UTC-4. I think this means that there wasn't a midnight in Argentina on May 5, 1920. When you convert that string to POSIXct, it interprets it at midnight that day in your local time zone, which by coincidence is a time that did not exist in Argentina. (This explains why it was not reproducible for others who tried the same code.)



    http://www.statoids.com/tar.html




    Locations in Argentina observed Local Mean Time until 1894-10-31 00:00
    (as measured after the transition). At that moment, the entire country
    synchronized on Córdoba's Local Mean Time, which was UTC-4:16:48. The
    next transition occurred at 1920-05-01 00:00, when clocks were set
    ahead sixteen minutes and forty-eight seconds to be an even UTC-4.
    Argentina remained unified on UTC-4 until its first daylight saving
    time was inaugurated in 1931.




    If you need a POSIXct object, you might consider:



    a) specifying a different time zone where midnight existed on that day.



    as.POSIXct("1920-05-01", tz = "UTC") 
    # Or perhaps other nearby time zones didn't have that specific problem?


    b) Storing the time in components, including one for date, and one for time within the day. e.g. time = hour(Time1) + minute(Time1)/60. It's a little unwieldy but it might be possible to perform the date / time calcs you need.






    share|improve this answer






























      2














      Your local settings appear to be based in Argentina. As it happens, Argentina reset their time zone on that date from UTC-4:16:48 to UTC-4. I think this means that there wasn't a midnight in Argentina on May 5, 1920. When you convert that string to POSIXct, it interprets it at midnight that day in your local time zone, which by coincidence is a time that did not exist in Argentina. (This explains why it was not reproducible for others who tried the same code.)



      http://www.statoids.com/tar.html




      Locations in Argentina observed Local Mean Time until 1894-10-31 00:00
      (as measured after the transition). At that moment, the entire country
      synchronized on Córdoba's Local Mean Time, which was UTC-4:16:48. The
      next transition occurred at 1920-05-01 00:00, when clocks were set
      ahead sixteen minutes and forty-eight seconds to be an even UTC-4.
      Argentina remained unified on UTC-4 until its first daylight saving
      time was inaugurated in 1931.




      If you need a POSIXct object, you might consider:



      a) specifying a different time zone where midnight existed on that day.



      as.POSIXct("1920-05-01", tz = "UTC") 
      # Or perhaps other nearby time zones didn't have that specific problem?


      b) Storing the time in components, including one for date, and one for time within the day. e.g. time = hour(Time1) + minute(Time1)/60. It's a little unwieldy but it might be possible to perform the date / time calcs you need.






      share|improve this answer




























        2












        2








        2







        Your local settings appear to be based in Argentina. As it happens, Argentina reset their time zone on that date from UTC-4:16:48 to UTC-4. I think this means that there wasn't a midnight in Argentina on May 5, 1920. When you convert that string to POSIXct, it interprets it at midnight that day in your local time zone, which by coincidence is a time that did not exist in Argentina. (This explains why it was not reproducible for others who tried the same code.)



        http://www.statoids.com/tar.html




        Locations in Argentina observed Local Mean Time until 1894-10-31 00:00
        (as measured after the transition). At that moment, the entire country
        synchronized on Córdoba's Local Mean Time, which was UTC-4:16:48. The
        next transition occurred at 1920-05-01 00:00, when clocks were set
        ahead sixteen minutes and forty-eight seconds to be an even UTC-4.
        Argentina remained unified on UTC-4 until its first daylight saving
        time was inaugurated in 1931.




        If you need a POSIXct object, you might consider:



        a) specifying a different time zone where midnight existed on that day.



        as.POSIXct("1920-05-01", tz = "UTC") 
        # Or perhaps other nearby time zones didn't have that specific problem?


        b) Storing the time in components, including one for date, and one for time within the day. e.g. time = hour(Time1) + minute(Time1)/60. It's a little unwieldy but it might be possible to perform the date / time calcs you need.






        share|improve this answer















        Your local settings appear to be based in Argentina. As it happens, Argentina reset their time zone on that date from UTC-4:16:48 to UTC-4. I think this means that there wasn't a midnight in Argentina on May 5, 1920. When you convert that string to POSIXct, it interprets it at midnight that day in your local time zone, which by coincidence is a time that did not exist in Argentina. (This explains why it was not reproducible for others who tried the same code.)



        http://www.statoids.com/tar.html




        Locations in Argentina observed Local Mean Time until 1894-10-31 00:00
        (as measured after the transition). At that moment, the entire country
        synchronized on Córdoba's Local Mean Time, which was UTC-4:16:48. The
        next transition occurred at 1920-05-01 00:00, when clocks were set
        ahead sixteen minutes and forty-eight seconds to be an even UTC-4.
        Argentina remained unified on UTC-4 until its first daylight saving
        time was inaugurated in 1931.




        If you need a POSIXct object, you might consider:



        a) specifying a different time zone where midnight existed on that day.



        as.POSIXct("1920-05-01", tz = "UTC") 
        # Or perhaps other nearby time zones didn't have that specific problem?


        b) Storing the time in components, including one for date, and one for time within the day. e.g. time = hour(Time1) + minute(Time1)/60. It's a little unwieldy but it might be possible to perform the date / time calcs you need.







        share|improve this answer














        share|improve this answer



        share|improve this answer








        edited Nov 16 '18 at 22:33

























        answered Nov 16 '18 at 22:13









        Jon SpringJon Spring

        7,0631829




        7,0631829
































            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%2f53326138%2fpossible-bug-in-as-posixct%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

            Bressuire

            Vorschmack

            Quarantine