1. Vitali Baruh Avatar Vitali Baruh
  2. Untitled project
  3. LocalTime

Wiki

Clone wiki

LocalTime / Home

View History

LocalTime

LocalTime is Google Chrome extension which converts timestamps from site time zone to your local time zone.

If you work with web applications (like bugzilla, jenkins, reviewboard, etc) which work in foreign time zone this is a must have extension. It will convert seamlessly time stamps found in a web page to your local time zone, so you will no longer calculate time differences by mind.

Table of contents

How to install

Install LocalTime from Google Web Store here.

You can see its change log here.

Functionality

How it works

  1. You should define your local time zone
  2. Then you should define one or more configuration set
  3. Each configuration set consists of:
  • List of sites on which to operate
  • List of time stamp format to look for
  • Foreign time zone - the time zone in which the specified sites work
  • Output time stamp format

When a page is loaded the extension checks whether its URL matches particular configuration set. If such is found the extension will look for time stamps in the specified formats. Each matched time stamp will be enclosed in a tag. Also the extension will add another tag with the converted time stamp value. Finally it will hide all elements which contain the original time stamps.

Pressing the extension button will change the visibility of the original and converted elements, so you will be able to see original content of the page.

Example

Let's say that:

  1. We are in Bulgaria, so our local time zone is "Europe/Sofia"
  2. We want to localize https://bugzilla.mozilla.org/, so we add this URL in site list
  3. We add the following time stamp format -> yyyy-mm-dd HH:MM:ss 'PDT'
  4. PDT means Pacific Daylight Time so we define that the site time zone is 'US/Pacific'
  5. Our output format will be yyyy-mm-dd HH:MM

The result is: Bugzilla with converted time stamps

And the original is: Bugzilla with original content

Performance

It is highly recommended to define a configuration set for those sites which use same time stamp format and operates in same time zone (despite it requires more clicking by the user).

It is not recommended to define multiple sites and multiple time stamp formats in same configuration set just because they share same time zone. This will impact page loading performance for all specified sites.

Implementation

External libraries used by LocalTime

  1. Date Format 1.2.3 written by Steven Levithan, improved by Scott Trenda and Kris Kowal http://blog.stevenlevithan.com/archives/date-time-format

  2. timezoneJS written by Matthew Eernisse https://github.com/mde/timezone-js

Time Zone Database

timezoneJS is javascript library based on The Time Zone Database. Therefore LocalTime also uses The Time Zone Database (tzdb).

Short quote from the tzdb site says:

The Time Zone Database (often called tz or zoneinfo) contains code and data that represent the history of local time for many representative locations around the globe. It is updated periodically to reflect changes made by political bodies to time zone boundaries, UTC offsets, and daylight-saving rules. Its management procedure is documented in BCP 175: Procedures for Maintaining the Time Zone Database.

More info about time zone database here.

Using timezoneJS, LocalTime is able to convert accurately time stamps from one time zone to another.

Preparsed tzdb

LocalTime works with preparsed timezone database.

Instructions to create preparsed file (copied from timezoneJS site):

  1. Download node-preparse.js and date.js from timezone-JS github page
  2. Download node.exe from nodejs.org
  3. Download latest tzdb data file from http://www.iana.org/time-zones
  4. Extract the tar.gz file

  5. Execute the following line:

    node.exe node-preparse.js tzdata2013a > zones.js

  6. Edit manually zones.js file:

    1. Insert "zonesData = " at the begining of the file. This way after this .js file is loaded zonesData variable will be initialized with zones and rules.
    2. Also add a new property to the json object with name "releaseInfo". The value should be string that describes the version and release date of time zonde db.
  7. Update zones.js file in extension source directory

Versioning

The four numbers of extension version should be read as follow: 1.0.2.1 major.minor.revision.tzdupdate

  • major probably won't change soon, since there's no big road map in front of this extension
  • minor - I guess that it could change if someone create more beautiful options page, better icon
    • minor will start from zero if major increments
  • revision - it will be incremented in each release which adds minor improvements or addresses issues
    • reviosion will start from zero if major or minor increments
  • tzupdate - it will be incremented when a newer version of tzdb is included in the extension
    • tzupdate - it will continue to increment without any depends to major/minor/revision fields

Contributions

Everybody is welcomed. There are no specific rules or requirements at the moment...

The extension needs better icon and more smooth options page interface...

To clone the source coude use:

    git clone https://bitbucket.org/vbaruh/localtime.git

or

    git clone git@bitbucket.org:vbaruh/localtime.git

Branching

Branch structure

There's a great article about git branching here http://nvie.com/posts/a-successful-git-branching-model/

I decided to follow everything written in this article.

Since version 1.0.3.2 the branching structure is:

  • master - the HEAD of this branch is always the latest released version of the extension
  • develop - main development branch. The HEAD of this branch contains all new features READY for publishing There are two important difference in manifest.json between master and develop branches.

1. For development purposes manifest.json in content_script/matches section and in permissions contains file:/// specifier. This allows to test with files located on local file system

2. There is hard-coded key in manifest.json. This is the extension identifier. Using the same key makes easier your life if you want to test local and synced storage, because the extension will be always installed under that identifier

  • feature (bug fix) branches -> The recommendation is to create a feature branch where to develop a new feature or fix a bug. Once the feature is ready it should be merged into develop branch. The feature branch is removed.

It is possible to work in develop branch instead of working in separate branch but this is risky - if you have to apply hot fix it will become hairy because: 1. you should move somehow all changes related with your current work somewhere; 2. then apply the the hot fix; 3. release; 4. bring back your current work in develop.

Just open new feature branch when you start working on a new feature or bug fix. Just do it.

  • release branches - a release branch is created before publishing new changes. In the release branch you have to
  1. change the version in manifest.json
  2. update the changelog.txt according to new features/bug fixes

When these changes are ready, this branch is merged into master and develop. We create a tag in master branch for the new release. Finally the release branch is removed

  • There is a branch with name "release" - it is no longer used, but I will keep it because the first releases went out from this branch. DO NOT USE IT any more.

Branching step-by-step instructions

Working with feature branches

  1. Create a feature branch

    # make sure you are in develop branch
$ git checkout develop

# create branch from current state of develop
$ git checkout -b my-feature

  2. Do you work and submit it in my-feature branch. When you commit write good and informative messages, they will go into develop branch.

  3. Merge your read feature into develop branch

    # checkot develop branch
$ git checkout develop

# merge my-feature branch with all its history, that's what --no-ff switch does
$ git merge --no-ff my-feature

  4. Publish your changes and remove feature branch

    # publish develop branch
$ git push origin develop

# remove my-feature branch
$ git branch -d my-feature

Release

  1. Make sure you have only ready for publishing features in develop branch

  2. Create a release branch from develop branch

    # checkout develop branch
$ git checkout develop

# create a release branch, put correct numbers for revision and tzupdate
$ git checkout -b release-1.0.X.X

  3. Update changelog.txt - put correct version number + good descriptive list of new features

  4. Update manifest.json by putting the correct version number
  5. Commit your changes in release-1.0.X.X branch

  6. Merge release-1.0.X.X in master, tag the master branch

    # checkout master
$ git checkout master

# merge release 1.0.X.X
$ git merge --no-ff release-1.0.X.X
$ git tag -a 1.0.X.X

  7. Merge release-1.0.X.X in develop

    # checkout develop
$ git checkout develop

# merge release 1.0.X.X
$ git merge --no-ff release-1.0.X.X

  8. Push master and develop to bitbucket

    $ git push --tags origin master
$ git push origin develop

  9. Remove release-1.0.X.X branch

    # remove release-1.0.X.X branch
$ git branch -d release-1.0.X.X

  10. Make a zip file and publish it on chrome webstore

    # make sure you are working with master branch
$ git checkout master
#
# zip src folder
$ zip ... blaaah

Bugs, feature requests, feedback

Share your feedback here -> https://bitbucket.org/vbaruh/localtime/issues

License

Copyright (c) 2013 Vitali Baruh. See MIT-LICENSE.txt for details.

Updated