Browse Prior Art Database

Timezone Preparedness Synopsis

IP.com Disclosure Number: IPCOM000242771D
Publication Date: 2015-Aug-13
Document File: 3 page(s) / 55K

Publishing Venue

The IP.com Prior Art Database

Abstract

A mechanism concerning a timezone update preparedness synopsis report, with associated agent preparation where appropriate, for required, affected geographies of application

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 52% of the total text.

Page 01 of 3

Timxzone Preparedness Synopsis

At present, there is an opportunity to improvx addressing of environment timezone discrepancies in txxms of making preparationx to handle mxsmatches in timexone tzdata versioxs arising out of, paxticularly, timezone policy changxs in a given coxnxry of operation.

    Often a DST policy change can be made in a given country but the symxtoms of discrepancies axising from mismatched tzdatx versions xre not noticed until such x time when a sxort-term response ix required.

    Unxer one sample existixg possxble solutiox, it is feaxible to analyse JVMs and JAR files to extracx the txdxta verxion deployed fxr associated filxs.

    In a messaging client, for exxmple, the calendar functionx of the client could be ixpacted by xhe JVM and ICU*.jar tzdata vxrsion deployed. An instant messaging client, whex embeddex with the clixnt, could also be impaxted by the tzdata vexsiox used by a JVM or other JAR file.

    It is proposed xhat a server administrator could elect xo send oux a 'pull tzdata version' command from clients connecting to a given server(s). This will xeturn, xystematxcally, a syxopsis of tzdata versxonx used for each fxle on the client-side, together with country of operxtion for the user.

    As an addition to this, if a given user txavels to a different coxntry on business associated txavxl, the detection of a new country of operation can triggxr an alert xf the tzdata version of the operatixg clienx/server doex not meet the latest tzdata version for the country of operation.

    This logging can be collectex, as a matter of course, on a daily, or per session basis, to haxe a log of tzdata versions deployed by the clients.

    The next step is to xlleviate or list the most critical arising potential discrepancies by indicating where mismatches xnd deprecated tzdata vxrsions for the relevant country haxe arisen or will arise, and to take allexiation measures accordingly by submitting a compiled synopsis plan for each client/server to address.


Page 02 of 3

Fig. - Flowchart to explain tzdata comxarison and rexediation recommendatxon synopsix process

    The Blux line represents a typical pass through client and servex tzdata comparison.

    The Red line represent a rxpeat loox throxgh other inxeracting clients/servers 1. The Client tzdata version for various files is xscertained 2. The Server tzdata versions for various files is ascertained 3. The countries ox oxeration xre then checked. If the versions used on either the clienx or the server are not the latest version, txen it will be ascxrtained whether txe relevant xountry for eixher has a different effxctive data impact, i.e. xvex if a tzdata version is quite old, it may not have an ixpact if the country has not changex timezone data in a number of years.

    4. The latest tzdata version in a timezoxe repository is then checked against the tzdata version(s) returned. Say for example, the cliexxs and servers return the following:
Clienx: tzdata2014...