Uploaded image for project: 'Confluence Data Center'
  1. Confluence Data Center
  2. CONFSERVER-35818

Blogposts are filed under the incorrect date

XMLWordPrintable

      It seems that when you publish a new blog post, the post date for the blog does not respect the user's timezone preference.

      The results are confusing: the page gets stored under yesterday's date in the breadcrumbs.

      See this screenshot. The post was created on Dec 4th @ 5PM'ish Pacific. It's filed under Dec 3rd! Our server is on UTC.

        1. Selection_273.png
          Selection_273.png
          24 kB

          Form Name

            [CONFSERVER-35818] Blogposts are filed under the incorrect date

            Fabian Haslwanter added a comment -

            I currently opened a ticket and it seems, that this bug (or a similar) is still around. It also seems, that it's a Daylight Saving Time issue and that a wrong timestamp gets saved, which is then delivered via the API.

            I really hope, that this gets addressed soon.

             

            Fabian Haslwanter added a comment - I currently opened a ticket and it seems, that this bug (or a similar) is still around. It also seems, that it's a Daylight Saving Time issue and that a wrong timestamp gets saved, which is then delivered via the API. I really hope, that this gets addressed soon.  

            Nikita Dvorkin added a comment -

            Dear Atlassian.

            Please make sure that this bug will be fixed together with https://jira.atlassian.com/browse/CONFSERVER-22560. I added explanation of importance there.

            Best regards,
            Nikita Dvorkin
            on behalf of SAP SE

            Nikita Dvorkin added a comment - Dear Atlassian. Please make sure that this bug will be fixed together with https://jira.atlassian.com/browse/CONFSERVER-22560 . I added explanation of importance there. Best regards, Nikita Dvorkin on behalf of SAP SE

            Jan B. added a comment -

            We have that Error now also. It's a really weird behaviour and occured after moving our instance to another cluster (basically a copy of the old cluster). Our test-instance which is still running on the old cluster doesn't show that behaviour even it is an exact copy.

            How is it possible that over 6 years after this bug seems to known there's not even a workaround? Was anyone able to solve this kind of behaviour? I wasn't able to find anything usable by now and seing todays posts as if they were from yesterday is super confusing for everyone.

            Jan B. added a comment - We have that Error now also. It's a really weird behaviour and occured after moving our instance to another cluster (basically a copy of the old cluster). Our test-instance which is still running on the old cluster doesn't show that behaviour even it is an exact copy. How is it possible that over 6 years after this bug seems to known there's not even a workaround? Was anyone able to solve this kind of behaviour? I wasn't able to find anything usable by now and seing todays posts as if they were from yesterday is super confusing for everyone.

            Paul DeSousa added a comment -

            Hello,

            Is there an ETA on this issue by chance?

            Thanks.

            Paul DeSousa added a comment - Hello, Is there an ETA on this issue by chance? Thanks.

              Unassigned Unassigned
              a38518e05741 David Yu
              Affected customers:
              14 This affects my team
              Watchers:
              13 Start watching this issue

                Created:
                Updated: