PostgreSQL what happens if TimeZone is not set?





.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty{ margin-bottom:0;
}







1















From the docs on 9.1, I see




If timezone is not specified in postgresql.conf or as a server command-line option, the server attempts to use the value of the TZ environment variable as the default time zone. If TZ is not defined or is not any of the time zone names known to PostgreSQL, the server attempts to determine the operating system's default time zone by checking the behavior of the C library function localtime(). The default time zone is selected as the closest match among PostgreSQL's known time zones. (These rules are also used to choose the default value of log_timezone, if not specified.)




This section was however removed subsequently in 9.2, what happens if 9.2+ is not specified in postgresql.conf or as a server command-line option?



My timezone currently says localtime and I'm wondering what exactly that means and how it's decided. The original text seems to answer it if it's still applicable. Are we still relying on the C library function localtime()?



# show timezone;
TimeZone
-----------
localtime
(1 row)


I was trying to add this information in this answer for completeness when I realized that the older docs had more details.










share|improve this question
















bumped to the homepage by Community 1 min ago


This question has answers that may be good or bad; the system has marked it active so that they can be reviewed.
















  • I'm about 95% sure it does the same thing on the server. So I'm not sure why they removed that in the docs.

    – Evan Carroll
    Jan 12 '17 at 22:36


















1















From the docs on 9.1, I see




If timezone is not specified in postgresql.conf or as a server command-line option, the server attempts to use the value of the TZ environment variable as the default time zone. If TZ is not defined or is not any of the time zone names known to PostgreSQL, the server attempts to determine the operating system's default time zone by checking the behavior of the C library function localtime(). The default time zone is selected as the closest match among PostgreSQL's known time zones. (These rules are also used to choose the default value of log_timezone, if not specified.)




This section was however removed subsequently in 9.2, what happens if 9.2+ is not specified in postgresql.conf or as a server command-line option?



My timezone currently says localtime and I'm wondering what exactly that means and how it's decided. The original text seems to answer it if it's still applicable. Are we still relying on the C library function localtime()?



# show timezone;
TimeZone
-----------
localtime
(1 row)


I was trying to add this information in this answer for completeness when I realized that the older docs had more details.










share|improve this question
















bumped to the homepage by Community 1 min ago


This question has answers that may be good or bad; the system has marked it active so that they can be reviewed.
















  • I'm about 95% sure it does the same thing on the server. So I'm not sure why they removed that in the docs.

    – Evan Carroll
    Jan 12 '17 at 22:36














1












1








1








From the docs on 9.1, I see




If timezone is not specified in postgresql.conf or as a server command-line option, the server attempts to use the value of the TZ environment variable as the default time zone. If TZ is not defined or is not any of the time zone names known to PostgreSQL, the server attempts to determine the operating system's default time zone by checking the behavior of the C library function localtime(). The default time zone is selected as the closest match among PostgreSQL's known time zones. (These rules are also used to choose the default value of log_timezone, if not specified.)




This section was however removed subsequently in 9.2, what happens if 9.2+ is not specified in postgresql.conf or as a server command-line option?



My timezone currently says localtime and I'm wondering what exactly that means and how it's decided. The original text seems to answer it if it's still applicable. Are we still relying on the C library function localtime()?



# show timezone;
TimeZone
-----------
localtime
(1 row)


I was trying to add this information in this answer for completeness when I realized that the older docs had more details.










share|improve this question
















From the docs on 9.1, I see




If timezone is not specified in postgresql.conf or as a server command-line option, the server attempts to use the value of the TZ environment variable as the default time zone. If TZ is not defined or is not any of the time zone names known to PostgreSQL, the server attempts to determine the operating system's default time zone by checking the behavior of the C library function localtime(). The default time zone is selected as the closest match among PostgreSQL's known time zones. (These rules are also used to choose the default value of log_timezone, if not specified.)




This section was however removed subsequently in 9.2, what happens if 9.2+ is not specified in postgresql.conf or as a server command-line option?



My timezone currently says localtime and I'm wondering what exactly that means and how it's decided. The original text seems to answer it if it's still applicable. Are we still relying on the C library function localtime()?



# show timezone;
TimeZone
-----------
localtime
(1 row)


I was trying to add this information in this answer for completeness when I realized that the older docs had more details.







postgresql timezone






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited Oct 5 '17 at 19:42







Evan Carroll

















asked Jan 12 '17 at 20:43









Evan CarrollEvan Carroll

33.4k1076232




33.4k1076232





bumped to the homepage by Community 1 min ago


This question has answers that may be good or bad; the system has marked it active so that they can be reviewed.







bumped to the homepage by Community 1 min ago


This question has answers that may be good or bad; the system has marked it active so that they can be reviewed.















  • I'm about 95% sure it does the same thing on the server. So I'm not sure why they removed that in the docs.

    – Evan Carroll
    Jan 12 '17 at 22:36



















  • I'm about 95% sure it does the same thing on the server. So I'm not sure why they removed that in the docs.

    – Evan Carroll
    Jan 12 '17 at 22:36

















I'm about 95% sure it does the same thing on the server. So I'm not sure why they removed that in the docs.

– Evan Carroll
Jan 12 '17 at 22:36





I'm about 95% sure it does the same thing on the server. So I'm not sure why they removed that in the docs.

– Evan Carroll
Jan 12 '17 at 22:36










1 Answer
1






active

oldest

votes


















0














It seems like PostgreSQL 10 still




  1. Looks at the environmental variable TZ first

  2. Proceeds to use the localtime library function.

  3. Looks under the shared directory or the system directory for matching timezone information.


So it seems like the 9.1 docs are still accurate as of PostgreSQL 10.



Internally, you can see the list of timezone information by using SELECT * FROM pg_timezone_names(); (here in the source) which calls pg_tzenumerate_start which the reads the shared directory or system directory above.






share|improve this answer


























    Your Answer








    StackExchange.ready(function() {
    var channelOptions = {
    tags: "".split(" "),
    id: "182"
    };
    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: false,
    noModals: true,
    showLowRepImageUploadWarning: true,
    reputationToPostImages: null,
    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%2fdba.stackexchange.com%2fquestions%2f160915%2fpostgresql-what-happens-if-timezone-is-not-set%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









    0














    It seems like PostgreSQL 10 still




    1. Looks at the environmental variable TZ first

    2. Proceeds to use the localtime library function.

    3. Looks under the shared directory or the system directory for matching timezone information.


    So it seems like the 9.1 docs are still accurate as of PostgreSQL 10.



    Internally, you can see the list of timezone information by using SELECT * FROM pg_timezone_names(); (here in the source) which calls pg_tzenumerate_start which the reads the shared directory or system directory above.






    share|improve this answer






























      0














      It seems like PostgreSQL 10 still




      1. Looks at the environmental variable TZ first

      2. Proceeds to use the localtime library function.

      3. Looks under the shared directory or the system directory for matching timezone information.


      So it seems like the 9.1 docs are still accurate as of PostgreSQL 10.



      Internally, you can see the list of timezone information by using SELECT * FROM pg_timezone_names(); (here in the source) which calls pg_tzenumerate_start which the reads the shared directory or system directory above.






      share|improve this answer




























        0












        0








        0







        It seems like PostgreSQL 10 still




        1. Looks at the environmental variable TZ first

        2. Proceeds to use the localtime library function.

        3. Looks under the shared directory or the system directory for matching timezone information.


        So it seems like the 9.1 docs are still accurate as of PostgreSQL 10.



        Internally, you can see the list of timezone information by using SELECT * FROM pg_timezone_names(); (here in the source) which calls pg_tzenumerate_start which the reads the shared directory or system directory above.






        share|improve this answer















        It seems like PostgreSQL 10 still




        1. Looks at the environmental variable TZ first

        2. Proceeds to use the localtime library function.

        3. Looks under the shared directory or the system directory for matching timezone information.


        So it seems like the 9.1 docs are still accurate as of PostgreSQL 10.



        Internally, you can see the list of timezone information by using SELECT * FROM pg_timezone_names(); (here in the source) which calls pg_tzenumerate_start which the reads the shared directory or system directory above.







        share|improve this answer














        share|improve this answer



        share|improve this answer








        edited Oct 5 '17 at 19:42

























        answered Oct 5 '17 at 19:30









        Evan CarrollEvan Carroll

        33.4k1076232




        33.4k1076232






























            draft saved

            draft discarded




















































            Thanks for contributing an answer to Database Administrators Stack Exchange!


            • 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%2fdba.stackexchange.com%2fquestions%2f160915%2fpostgresql-what-happens-if-timezone-is-not-set%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

            SQL Server 17 - Attemping to backup to remote NAS but Access is denied

            Always On Availability groups resolving state after failover - Remote harden of transaction...

            Restoring from pg_dump with foreign key constraints