1 answer

1.  

   2

   1

   0

   • Tomás Martynowicz
   • Mar 03, 2022

   This can happened due to Jira Server being located -1 or less hours from Jira cloud's or other platforms.

   The problem here is that Jira stores datetime using local timezone thus if due date is synced, the time is set at the start of the day (because it is the default time) and when destination side updates the issue's due date it does using local timezone (substract 1 or more hours) giving as a result a previous day.

   A workaround for this issue is to send and receive due date as an epoch day and creating a new date at start of day using local timezone like:

   
   

   Outgoing script

   replica.dueAsEpochDay = toEpochDay(issue.due)
   
   
   //Helper function that converts Date into epoch day in order 
   // to avoid handling time when sending due date into the remote side
   import java.time.ZoneId
   
   def toEpochDay(date) { 
       
       def localTimeZone = ZoneId.systemDefault()
       return date
           ?.toInstant()
           ?.atZone(localTimeZone)
           ?.toLocalDate()
           ?.toEpochDay()
   } 
   
   

   
   

   Incoming Script

   issue.due = fromEpochDay(replica.dueAsEpochDay)
   
   //Helper function that converts epoch day into Date 
   // at start of day using local timezone
   import java.time.ZoneId
   import java.time.LocalDate
   
   def fromEpochDay(epochDay) { 
       if(epochDay == null)
           return null;
       
       def localTimeZone = ZoneId.systemDefault()
       return Date.from(LocalDate
               .ofEpochDay((Long) epochDay)
               .atStartOfDay(localTimeZone)
               .toInstant())
   }

   •  Comment

   CommentAdd your comment...