Hi, @Charini, Thanks for the details. I will look into it.
@Roshan, This will only affect the current application. On Thu, Aug 24, 2017 at 10:59 AM, roshan wijesena <[email protected]> wrote: > @Anuruddha, does it change the JVM default time zone to UTC? Will it > affect to other vendors which are installed on that JVM? > > On Wed, Aug 23, 2017 at 8:23 PM, Charini Nanayakkara <[email protected]> > wrote: > >> Hi, >> >> The requirement to consider time zones was encountered in the recent >> implementation we did for incremental processing with Siddhi as well. For >> this, we have used the java.time package available in java 8 [1]. The >> Instant class allows you to specify a time in UTC, whereas we can >> use ZonedDateTime class where some other time zone is concerned. I found >> this article [2] on Java 8 date/ time API quite useful. It allows you to >> easily convert to and from an epoch time as well. >> In incremental processing implementation, the user has the capability of >> giving a time in ISO-8601 format. (e.g: 2017-06-01 09:30:00 +05:30). If a >> user queries for data related to 2017-06-01 04:00:00 (in UTC time), it >> would return data that is stored for 2017-06-01 09:30:00 +05:30 as well >> (since it reflects the same time, but in different time zones). With the >> use of Java date/time API, we can easily do this matching. Hope this helps. >> >> Thanks >> Charini >> >> >> [1] https://docs.oracle.com/javase/8/docs/api/java/time/pack >> age-summary.html >> [2] https://dzone.com/articles/deeper-look-java-8-date-and >> >> On Wed, Aug 23, 2017 at 3:09 PM, Anuruddha Liyanarachchi < >> [email protected]> wrote: >> >>> Hi, >>> >>> As per the current implementation of C5, we are storing the timestamp >>> values in the APIM server's default time zone. >>> >>> We have faced many issues in the past due to the mismatch between client >>> browser time zone and server's time zone which results in the display of >>> incorrect data. >>> >>> >>> *Solution:* >>> >>> 1. Store date time in UTC along with the origin timezone. >>> UTC is the least widely used format to store times, as it does not >>> denote any timezone offset. This allows to purpose dates as needed >>> throughout the system in whatever timezone is appropriate. >>> >>> 2. Return time zones in UTC >>> UTC will allow API consumers the freedom to offset the date to their >>> local time zone. >>> The react applications will have to convert the time zone from UTC to >>> browser time zone. >>> >>> >>> *Implementation:* >>> The current implementation we are setting the time stamp as below which >>> returns the time in local time zone. >>> >>> Timestamp.valueOf(LocalDateTime.now()); >>> >>> >>> We can force the JVM to use UTC at the startup using, >>> >>> TimeZone.setDefault(TimeZone.getTimeZone("Etc/UTC")); >>> >>> then Timestamp.valueOf(LocalDateTime.now()) will return time stamp in UTC. >>> >>> >>> Appriciate your thoughts on this. >>> >>> -- >>> *Thanks and Regards,* >>> Anuruddha Lanka Liyanarachchi >>> Software Engineer - WSO2 >>> Mobile : +94 (0) 712762611 >>> Tel : +94 112 145 345 >>> a <[email protected]>[email protected] >>> >> >> >> >> -- >> *Charini Vimansha Nanayakkara* >> Software Engineer at WSO2 >> >> Mobile: 0714126293 >> E-mail: [email protected] >> Blog: http://www.charini.me/ >> >> <http://wso2.com/signature> >> >> _______________________________________________ >> Architecture mailing list >> [email protected] >> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >> >> > -- *Thanks and Regards,* Anuruddha Lanka Liyanarachchi Software Engineer - WSO2 Mobile : +94 (0) 712762611 Tel : +94 112 145 345 a <[email protected]>[email protected]
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
