Uploaded image for project: 'Couchbase Server'
  1. Couchbase Server
  2. MB-42488

[Backup Service] Existing repositories not aware of timezone changes.

    XMLWordPrintable

Details

    • Bug
    • Status: Closed
    • Major
    • Resolution: Won't Fix
    • Cheshire-Cat
    • 7.0.0
    • tools

    Description

      Description:

      The next scheduled time is not updated when the timezone changes.

       

      Steps to reproduce:

      1. Start a hourly backup plan at 0745 on the 6th of November with the time set as UTC.
      2. Take the next scheduled backup at 9am UTC time.
      3. Change the timezone to Pacific/Apia.
      4. At this point it's okay for the backup service to not be aware of the timezone change as the next scheduled time was calculated according to the UTC timezone.

      So we can take the next scheduled backup in 1 hour as expected.

      The task history currently looks like this after the backup:

      1. At this point the backup service should become aware of the timezone change as it recalculates the next scheduled time for task0, however it still reports the next scheduled time in UTC.

      Expected behaviour:

      I expected the next time to account for the timezone change.

      Side note:

      I created another repository and it also calculates the next time in UTC.

      This is super weird as the code calls time.Now() to calculate the next time which should account for the timezone.

      Attachments

        No reviews matched the request. Check your Options in the drop-down menu of this sections header.

        Activity

          I have confirmed my theory. time.Now() does not update the timezone if it changes from when the go program was originally invoked. This is very easy to test run the following program and change the timezone whilst is running and you can see that the time returned does not change. If you ^C it and restart it the new time zone will be reflected.

          My understanding of why this is that the runtime cahces the lcoation at the start and keeps using the same one. I have not managed to get a lot of literature about the specifics unfortunately.

          package main
           
          import (
          	"encoding/json"
          	"net/http"
          	"time"
          )
           
          func main() {
          	http.HandleFunc("/time", func(writer http.ResponseWriter, _ *http.Request) {
          		out, _ := json.Marshal(time.Now())
          		writer.WriteHeader(http.StatusOK)
          		_, _ = writer.Write(out)
          	})
           
          	_ = http.ListenAndServe(":6721", nil)
          }
          

          I also found this issue in the go repository which is still open and kind of abandon but showcase thise exact issue. https://github.com/golang/go/issues/28020. I believe the onyl way around it would be doing a platform dependeant system call to get the system time, but I am not sure if it is worth it what do you gusy think, Patrick Varley James Lee Asad Zaidi

          carlos.gonzalez Carlos Gonzalez Betancort (Inactive) added a comment - I have confirmed my theory. time.Now() does not update the timezone if it changes from when the go program was originally invoked. This is very easy to test run the following program and change the timezone whilst is running and you can see that the time returned does not change. If you ^C it and restart it the new time zone will be reflected. My understanding of why this is that the runtime cahces the lcoation at the start and keeps using the same one. I have not managed to get a lot of literature about the specifics unfortunately. package main   import ( "encoding/json" "net/http" "time" )   func main() { http.HandleFunc("/time", func(writer http.ResponseWriter, _ *http.Request) { out, _ := json.Marshal(time.Now()) writer.WriteHeader(http.StatusOK) _, _ = writer.Write(out) })   _ = http.ListenAndServe(":6721", nil) } I also found this issue in the go repository which is still open and kind of abandon but showcase thise exact issue. https://github.com/golang/go/issues/28020 . I believe the onyl way around it would be doing a platform dependeant system call to get the system time, but I am not sure if it is worth it what do you gusy think, Patrick Varley James Lee Asad Zaidi
          asad.zaidi Asad Zaidi (Inactive) added a comment - - edited

          I have few thoughts on the matter:

          As long as the backup service works correctly throughout the timezone changes, which I believe it does, I think that the impact of this bug is visual as far as my understanding goes. There are some interesting 'visual' situations which can happen. For example, suppose a backup node is killed and restarts and gives time in current timezone. Then that node is killed again and it elects a leader which is working in the old timezone as it has not been restarted. This won't affect the actual behaviour of the backup service.

          Perhaps adding platform depending calls to obtain the current timezone may introduce more complexity and the potential for bugs instead and a better approach may be to defer the fix for this until a better solution is found. 

          In addition, It may not be worth fixing it at all, until a CBSE is raised.

          asad.zaidi Asad Zaidi (Inactive) added a comment - - edited I have few thoughts on the matter: As long as the backup service works correctly throughout the timezone changes, which I believe it does, I think that the impact of this bug is visual as far as my understanding goes. There are some interesting 'visual' situations which can happen. For example, suppose a backup node is killed and restarts and gives time in current timezone. Then that node is killed again and it elects a leader which is working in the old timezone as it has not been restarted. This won't affect the actual behaviour of the backup service. Perhaps adding platform depending calls to obtain the current timezone may introduce more complexity and the potential for bugs instead and a better approach may be to defer the fix for this until a better solution is found.  In addition, It may not be worth fixing it at all, until a CBSE is raised.
          james.lee James Lee added a comment - - edited

          This makes sense, if we look at the code we can see that it uses a 'sync.Once' to load the local timezone

          var localLoc Location
          var localOnce sync.Once
           
          func (l *Location) get() *Location {
          	if l == nil {
          		return &utcLoc
          	}
          	if l == &localLoc {
          		localOnce.Do(initLocal)
          	}
          	return l
          }
          

          We can see that they use a pointer to the local timezone 'var Local *Location = &localLoc' and that when getting the location when the pointer is equal to 'localLoc' it will trigger the loading of the local timezone (where it can be determined from multiple locations, falling back to UTC). It doesn't look like you're manually able to re-trigger this loading of the local timezone after the program is initially invoked (as you say). Note that 'time.Now()' uses this 'localLoc' value.

          From my point of view, I don't think it's the end of the world to require the user to restart the service when changing timezones, although, I don't recall how the other services behave; considering some others are written in Go I imagine they also face this same problem.

          EDIT: Didn't refresh before commenting so the timeline may look a little bit odd...

          james.lee James Lee added a comment - - edited This makes sense, if we look at the code we can see that it uses a ' sync.Once ' to load the local timezone var localLoc Location var localOnce sync.Once   func (l *Location) get() *Location { if l == nil { return &utcLoc } if l == &localLoc { localOnce.Do(initLocal) } return l } We can see that they use a pointer to the local timezone ' var Local *Location = &localLoc ' and that when getting the location when the pointer is equal to ' localLoc ' it will trigger the loading of the local timezone (where it can be determined from multiple locations, falling back to UTC). It doesn't look like you're manually able to re-trigger this loading of the local timezone after the program is initially invoked (as you say). Note that ' time.Now() ' uses this ' localLoc ' value. From my point of view, I don't think it's the end of the world to require the user to restart the service when changing timezones, although, I don't recall how the other services behave; considering some others are written in Go I imagine they also face this same problem. EDIT: Didn't refresh before commenting so the timeline may look a little bit odd...
          owend Daniel Owen added a comment -

          Hi Carlos Gonzalez Betancort I think we can close as Won't fix.

          owend Daniel Owen added a comment - Hi Carlos Gonzalez Betancort I think we can close as Won't fix.

          I am with Dan in this one if it ever becomes an issue in production we can re-tackle it.

          carlos.gonzalez Carlos Gonzalez Betancort (Inactive) added a comment - I am with Dan in this one if it ever becomes an issue in production we can re-tackle it.

          People

            carlos.gonzalez Carlos Gonzalez Betancort (Inactive)
            asad.zaidi Asad Zaidi (Inactive)
            Votes:
            0 Vote for this issue
            Watchers:
            5 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved:

              Gerrit Reviews

                There are no open Gerrit changes

                PagerDuty