Highlights: Time Series Database Service Beta Welcome to the International Informix Users Group (IIUG) Insider! Designed for IIUG members and Informix user group leaders, this publication contains timely and relevant information for the IBM Informix community. Contents:
Dear IIUG friends, The polls are open for the 2014 IIUG Board of Directors election. For me, serving on the IIUG Board is a challenge. I have several roles on the Board but the one you are probably familiar with is editing the IIUG Insider. This is my 99th issue. I hope you enjoy it. I certainly enjoy doing it. Editing the Insider is mainly searching for content. I would like to thank my loyal content providers for keeping the Insider going. Informix is now part of the Internet Of Things and Cloud initiatives and hence is part of the IBM vision. The new NoSQL capabilities alongside with the enhancement of Time Series capabilities, reignites my hopes for Informix. The IIUG Board and the IIUG community have a major role making sure Informix remains an important part of the IBM software portfolio. So please vote for the people you would like to see on the 2014 Board. I hope I am one of them. I'd love to do my 100th IIUG Insider in June. To vote go to the IIUG website, or directly to the ballot at http://www.iiug.org/about/2014_ballot.html. Gary Ben-Israel
Time Series Database Service Beta IBM announces new beta in Bluemix for additional bigdata Analytics for timeseries and geospatial applications in the cloud. Rapidly develop web and mobile applications to provide new services to your customers in record time.
Get started with the Internet of things to harness the immense volume of data generated by connected devices, sensors and gateways. IBM recently announced a new beta service in Bluemix using TimeSeries in the Internet of Things Service.
Register for IBM Insight 2014, the Big Data conference This year, hear thought about the emerging Internet of Things and how it's transforming our lives and how we do business. Ubiquitous computing and the proliferation of connected devices and sensors is producing enormous amounts of data, as well as unprecedented opportunities for growth. Register today and look for sessions on Internet of Things to learn about new, innovative and intelligent solutions from Informix that can harness this data to meet the challenges of IoT and transform your business.
Connected Devices for Smarter Home Environments IBM Data Magazine: Connected Devices for Smarter Home Environments - Internet of Things data bolstered by Informix database embedding advances connected devices at home VideosInternet of Things - Introduction Internet of Things with IBM Informix BlogsDevices are talking in the era of big data: Are you ready?
Webcast: Internet of Things: Choose an Intelligent Database June 5, 2014 | 1:00 p.m. Eastern / 10:00 a.m. Pacific The "Internet of Things" refers to the growing number of devices and sensors that communicate and interact via the Internet, offering businesses new customers and revenue opportunities. Harnessing data from billions of connected devices lies in the ability to store, access, and query SQL and NoSQL data together, seamlessly. Check out this upcoming eSeminar to learn how to bridge the gap between new computing technologies designed for big data, cloud, and mobile computing with the enterprise world of relational data in the "Internet of Things" era. Tech Talk: Developing Internet-Connected and Mobile Applications using DB2 and InformixJune 4, 2014 | 12:30 PM Eastern This webcast explains how Informix and DB2 can be used to bridge the gap between new computing technologies (Big Data, Cloud, Mobile) and enterprise relational data in the "Internet of Things" era. For example, SQL and NoSQL data used together seamlessly. Attend by clicking on the easy button below. This launches a new email widow with an invitation in it. You can personalize this message and add your client's email address and send. IBM IoT and NoSQL RoadshowDon't miss the new series of free one-day roadshows featuring Internet of Things and NoSQL solutions. IBM is offering both business and technical enablement sessions to present the latest technologies for harnessing your data and how to improve business outcomes. Look for a city near you and register today. Hildebrand Case StudySee how IBM client, Hildebrand, found a game-changing technology to provide energy monitoring services, process huge volumes of sensor data from devices on the edge and provide new services to their customers. Hildebrand recently used its Smart platform to launch a retail "footfall" tracking solution to use anonymized data from mobile devices to measure the approximate location of people over time. Across 25 UK shopping malls, the solution is currently collecting 250 million data points a day, delivering unprecedented insight to the mall operators. Informix 12.1 BootcampLocation: Gurgaon, India Hurry - seats are limited and are closing out fast.
Achieving Consistent Meanings for DATETIME Values with JDBC The best-fit Java class for an Informix DATETIME value is java.sql.Timestamp. Java.sql.Timestamp technically inherits from java.util.Date; although, there are some semantic differences which are not typical of inheritance relationships. All the constructors, getters, and setters which are not deprecated for Date and Timestamp use values based on Greenwich Mean Time (GMT). They are offsets in milliseconds from the epoch, January 1, 1970 00:00:00 GMT. So, it would be logically consistent for Timestamps to convert to DATETIMEs using the GMT reference frame by default. However, the JDBC Tutorial and Reference specifies that, when no Calendar is provided, Timestamp values are converted to the time zone of the JVM in which the application is running. The difficulties surrounding Timestamps and time zones are not limited to the scope of the Informix JDBC driver; they are generic to all of JDBC because that is the specification. This model creates problems in a variety of ways. For distributed applications, the Date or Timestamp values might be streaming into the database from JDBC drivers located in different time zones. With multi-tier applications, you might find yourself contending with a user interface in time zone A, the JDBC driver in time zone B, and the database server in time zone C. The driver is the library where external types are converted to internal types; so, where it is running is where the local time zone comes into play. It can be difficult for either the front end or the database to know in what time zone the driver is operating. Dealing with the conversion from Timestamp in GMT to DATETIME in the JDBC driver locale has to be done in the application layer directly interfacing with the JDBC driver. The conversion done by the driver applies in both directions, and this can lead to complications if anything other than the JDBC Timestamp class is used in conjunction with DATETIME values. If strings representing DATETIMEs or DATETIME literals are used anywhere in your application SQL (including CURRENT), the values will not be converted on the way in, but will be converted on the way out. Similarly, different APIs will not convert in either direction. If you insert new Timestamp(86400001) (January 2, 1970 00:00:00.001 GMT) through JDBC, and select it back from within the same JVM, you will get that same value back. So, you might expect that selecting the same row-column from, say, DBAcccess, would also give you the same value, but it will not because the value was converted to JVM time zone on the way in through JDBC, but not converted on the way out through ESQL/C. If you are in the U.S., you will get some time on January 1st, not even the same day. The reverse also applies, you may find yourself with values inserted through other APIs, which perform no conversion, that are converted to some other time zone when selected through JDBC. DATETIMEs, of course, do not contain time zone information. There are basically two ways to deal with this, record the time zone information in another column along with the DATETIME or establish a convention that all the DATETIMES in the database are in the same time zone. Establishing a convention is the simpler approach both from an application implementation perspective, and in terms of being able to easily compare values in different rows, columns, or tables. If you know that every Java application which will ever access the data will operate in its own JVM, you can code your applications to set the default time zone of the JVM, but this is a problematic solution when more than one, independent application is running in the same JVM, such as servlets in a web server. It is unclear what would happen with different threads of execution changing the time zone for all other threads, but if they were actually able to do that, it would not be pretty. At JDK 1.1 two things happened, all the getters and setters for java.util.Date where the meaning was ambiguous with respect to time zone were deprecated and the java.util.Calendar class was introduced. Along with the Calendar class itself, methods accepting a Calendar object were added to the JDBC interface, for example PreparedStatement.setTimestamp(int parameterIndex, Timestamp x, Calendar cal) and ResultSet.getTimestamp(int columnIndex, Calendar cal). In these methods, the Calendar object establishes the frame of reference used to convert from the GMT offset in the Timestamp object to or from a DATETIME value. If you create a constant Calendar object in your applications, and use it every time you read or write a Timestamp object to a DATETIME, the values DATETIME will remain consistent with each other, and the meaning of the value will not change dependent on the time zone of the JVM. Using a GMT calendar would be efficient because it requires less operations to convert between the Java classes and the value in the database. Also, the value will not change if other APIs, like ODBC or ESQL/C, are used. Conceptually, what is stored in the database is January 1, 1970 00:00:00.000 GMT + tstamp.getTime() milliseconds.
Coordinated Universal Time (UTC) is a close relative to GMT and is just as viable. In this model, all date and time values in the database are on the same time line, and conversion to other time lines or calendar systems are handled at the user interface level. Using UTC or GMT for all DATETIME values provides a simple model to implement in applications. It also removes all the problems related to knowing the time zone of the JDBC driver runtime or if applications written in anything other than Java will ever be used to access the data. - Chris Golledge
IBM Informix home page http://www.informix.com or directly at: http://www-01.ibm.com/software/data/informix/ Informix blogs and wikisBlogs and Wikis that have been updated during the last month
More Blogs and Wikis Forums, groups, videos, and magazines
There is now an Informix group on LinkedIn. The group is called "Informix Supporter", so anyone loving Informix can join, from current IBM employees, former Informix employees, to users. It will also be a good occasion to get in touch with others or long-time-no-seen friends. If you fancy showing the Informix logo on your profile, join.
http://www.iiug.org/quicklinks.html
The International Informix Users Group (IIUG) is an organization designed to enhance communications between its worldwide user community and IBM. The IIUG's membership database now exceeds 25,000 entries and enjoys the support and commitment of IBM's Data Management division. Key programs include local user groups and special interest groups, which we promote and assist from launch through growth.
For comments, please send an email to gary@iiug.org. |