Uploaded image for project: 'RHEL'
  1. RHEL
  2. RHEL-56496

DST is not taken into account when converting struct tm to time_t using mktime/timelocal.

    • Icon: Bug Bug
    • Resolution: Not a Bug
    • Icon: Major Major
    • None
    • rhel-9.4
    • glibc
    • No
    • Moderate
    • Customer Escalated
    • rhel-sst-pt-libraries
    • ssg_platform_tools
    • 1
    • False
    • Hide

      None

      Show
      None
    • None
    • Red Hat Enterprise Linux
    • None
    • None
    • None
    • None

      What were you trying to do that didn't work?

      When attempting to convert a struct tm to time_t using functions such as timelocal or mktime, DST is not observed or respected. This means that, during DST, applications with this behavior show a time that is an hour behind actual time.

      Please provide the package NVR for which bug is seen:

      libstdc++-11.4.1-3.el9.x86_64
      gcc-toolset-13-libstdc++-devel-13.3.1-2.el9_4.x86_64
      gcc-c++-11.4.1-3.el9.x86_64
      gcc-toolset-12-gcc-c++-12.2.1-7.6.el9_4.x86_64

      How reproducible:
      Consistently

      Steps to reproduce
      1. Compile reproducer .cpp file in attachments.
      2. Run output program.
      3. Observe behavior.

      Expected results

      DST is taken into account and time's outputted match correct time.

      Actual results:

      DST is not respected. Test application ran during DST still reports time that is an hour before.

      Additional:
      Customer this is filed for has given the OK to provide their reproducer as an attachment for your use.

              Unassigned Unassigned
              brclark@redhat.com Brandon Clark
              Brandon Clark
              Florian Weimer Florian Weimer
              qe-baseos-tools-bugs@redhat.com qe-baseos-tools-bugs@redhat.com qe-baseos-tools-bugs@redhat.com qe-baseos-tools-bugs@redhat.com
              Votes:
              0 Vote for this issue
              Watchers:
              12 Start watching this issue

                Created:
                Updated:
                Resolved: