Chronos

2006-04-06

Sci/Tech: Nanopore Method Could Revolutionize Genome Sequencing

Nanopore Method Could Revolutionize Genome Sequencing from PhysOrg.com

A team led by physicists at the University of California, San Diego has shown the feasibility of a fast, inexpensive technique to sequence DNA as it passes through tiny pores. The advance brings personalized, genome-based medicine closer to reality.
[...]

2006-04-05

Beware of geeks...wearing gifs :-)

Labels: technology

Or, Chameleon clothing lets you vanish into the background from PhysOrg.com

A chemist in the United States is working on "chameleon clothing" that at the touch of a switch would mimic the wearer's surroundings, New Scientist says.
[...]

2006-04-04

Numerology

Labels: Chronos, numerology, Smalltalk

Tomorrow morning, there will come a moment whose local time (in North American notation) will have the designation 04/05/06 07:08:09 (April 5, 2006.)

Next month (using YY-MM-DD notation,) the date-time designation 06-05-04 03:02:01 will occur (2006-May-04.)

In June, we'll have 06/06/06 06:06:06.

Later this year, at Noon of 21 September 2006, will occur Julian Day 2454000--which is one or two days before the Autumnal Equinox (depending on your time zone.)

Sci/Tech: Professor Predicts Human Time Travel This Century

Labels: science

Professor Predicts Human Time Travel This Century from PhysOrg.com

With a brilliant idea and equations based on Einstein’s relativity theories, Ronald Mallett from the University of Connecticut has devised an experiment to observe a time traveling neutron in a circulating light beam. While his team still needs funding for the project, Mallett calculates that the possibility of time travel using this method could be verified within a decade.
[...]

Sci/Tech: Chaos=Order: Physicists make baffling discovery

Labels: science

Chaos=Order: Physicists make baffling discovery from PhysOrg.com

"Da police are not here to create disorder; dere here to preserve disorder." -Richard J. Daley, Chicago mayor, explaining to the media the role of the police during the riotous 1968 Democratic National Convention.

Police keep order. That's why, for example, they issue tickets for "disturbing the peace." Thus the only logical conclusion to Mayor Daley's famous quote above – other than dismissing it as the result of a tangled tongue – is sometimes disorder spawns order. Sounds impossible, right? Wrong.
[...]

Sci/Tech: Device Only Atoms Across May Allow Infinitesimal But Powerful Computers

Labels: science, technology

Researchers at the University of Chicago recently created a single-molecule diode only a few tens of atoms in size and 1,000 times smaller than its conventional counterparts. Theorists from the University of South Florida and the Russian Academy of Sciences recently determined how the device works. The researchers found electron energy levels in a molecule are efficient channels for transferring electrons from one electrode to another. (Credit: Trent Schindler, National Science Foundation)

Link: Device Only Atoms Across May Allow Infinitesimal But Powerful Computers

2006-04-03

Version 2006c of the Chronos Time Zone Repository Published

Labels: Chronos, release, Smalltalk, timezone repository

Arthur David Olson published version 2006c of the Olson Time Zone Database today. Consequently, version 2006c of the Chronos Time Zone Repository has been published--both the Chronos-native and XML versions are available from date-time-zone.com.

Bug Report

Labels: bugs, Chronos, Smalltalk

A Chronos bug was reported to me earlier today. I'd say who made the report, except in the absence of permission to do so, it's better to err on the side of personal privacy.

The bug is in the method LocalTimeCalendarClock>>basicTodayIn:. The symptom is an MNU #subtractSeconds:. The fix is to replace "subtractSeconds: now secondsSinceStartOfDay" with "addSeconds: now secondsSinceStartOfDay negated". Note that the erroneous code never runs in an environment where the system clock reports Universal Time, and not local time. In other words, you won't see it unless you are using Chronos in either Squeak, or in a pre-7x version of VisualWorks on a non-Unix host platform.

The reason for the bug is simply that I had removed all the #subtractSeconds: methods (which, before I removed them, could only successfully have been sent to mutable Chronos objects, and were not part of the public API,) in favor of only supporting #addSeconds: with a negated argument. In other words, when the code in question was written, it was not a bug.

How I missed this (and one other) sender when I removed all the #subtractSeconds: methods from Chronos I have no idea, unless perhaps it had something to do with the fact that there are non-Chronos implementers and senders of #addSeconds: in VisualWorks.

How I missed the resulting bug is easy to explain: I use VW 7.4 as my main development platform (where the code would never execute,) and my test procedure for Squeak didn't have adequate coverage, because up to now I've been more concerned with the correctness of the infrastructural/platform-specific code in Squeak, under the (now-revealed-to-be faulty) assumption that my test coverage in VisualWorks 7.4 would be good enough for everything else.

The fix is in both the Squeak and VisualWorks download archives, available from the Chronos web site.

2006-04-02

Chronos Version B1.160 Published: Time Zone Rulesets Over HTTP

Labels: Chronos, release, Smalltalk, timezone repository

Chronos Version B1.160 has been publised ("Beta Release 1--build 160".) Chronos B1.160 is available for both VisualWorks and Squeak. The Chronos Seed Archive for B1.160 is also available (the "Chronos Seed" is the platform-independent Chronos codebase, used for porting Chronos from VisualWorks to other Smalltalk pltatforms.)

Chronos Version B1.160 can be obtained from the Chronos Web Site. The VisualWorks version can also be obtained from the Cincom Public StORE Repository. Or you can use either the direct download link for VisualWorks or the direct download link for Squeak.

The Chronos Time Zone Repository is included in the download archive. Be sure to follow the Chronos Installation Instructions--especially if you have not already done so for a previous version of Chronos.

If you are reinstalling Chronos into an image in which an earlier version is already resident, and do not install the new version from the Cincom Public StORE Repository using StORE, it is necessary to first remove the earlier version. StORE has been able to correctly install the new version on top of every earlier version I have tried--but I haven't tried them all.

About Chronos Version B1.160

Chronos Version B1.160 is able to retrieve the ruleset of any Olson-defined time zone, on demand, over HTTP. As far as I have been able to determine, Chronos is the only date/time library in the world with such a capability. If that's so, then this is a significant "first" for Smalltalk, in my humble opinion.

However, by default Chronos version B1.160 does not attempt to retrieve time zone rulesets over HTTP, for three reasons:

1. It is wise to avoid relying on new code when there is no clear need to do so.

2. The local filesystem probably has a higher availability than a remote HTTP server would have. To put it in "enterprise speak" (heh,) the local filesystem can probably be expected to meet a more demanding SLA.

3. Retrieving time zone rulesets over HTTP is significantly slower than from the local filesystem. This is hardly noticeable in the case of a single time zone, but becomes noticeable even when retrieving as few as five zone rulesets (according to my tests using a 4Mbit/second broadband connection.)

In spite of the above caveats, there are definitely cases where it makes great sense to retrieve time zone rulesets from a time zone server over HTTP, and not from the local filesystem. The same goes for a lot of other common reference data, such as locale information, holiday rules, the UTC leap second schedule, the current and/or historical prices of stocks, currencies and commodities, the dictionary definitions of words, help text, and numerous other examples.

The reasons for obtaining reference data over HTTP from a well-known, canonical source, in spite of the above concerns, are several:

1. Although reference data is usually relatively static, that's not always the case. It does change--and keeping all users up to date with the latest reference data can be quite a challenge for software vendors/distributors.

2. If reference data is kept locally, then the local application must manage it. That includes keeping track of of its location in the user's filesystem. Such information can and does get lost.

3. If each application is separately responsible for managing reference data, then not only does that involve a lot of duplicated effort on the part of the world's software vendors/distributors, it also puts the user at risk of getting different answers to the same questions from different applications. In other words, it presents a "reference data integrity" issue.

4. Reference data can usually be obtained without the need of CGI, servlets, EJBs, SOAP or "Web Services." More often than not, a RESTian architecture is quite sufficent. The Chronos architecture for reference data retrieval over HTTP is RESTian--an HTTP server is all that's needed.

5. Ajax applications typically don't have access to the local filesystem.

To configure Chronos so that it will retrieve time zone rulesets over HTTP from the default Chronos time zone server, evaluate the following "do it":


ChronosSystemFacade current resourcePathPrefix: 'http:///'

The above "do it" answers either true or false. If it answers false, then Chronos was not able to verify that the Chronos Time Zone Repository was accessible from the default Chronos time zone rule server, and the image will continue to use the local time zone repository. If it answers true, then the image will satisfy all future requests for a time zone ruleset from the Chronos time zone server over HTTP, until either a) it is told to use the local filesystem, or b) it is unable to connect to the time zone server on image startup.

To instruct Chronos to stop using the Chronos time zone server over HTTP to access the Chronos Time Zone Repository, and to instead access the time zone repository on the local filesystem at a specified path, evaluate a "do it" such as one of the following examples:


ChronosSystemFacade current resourcePathPrefix: nil. 
 "The first example makes Chronos look in the 
 current directory for the TZ repository"

ChronosSystemFacade current resourcePathPrefix: '/usr/local/reference/'. 

ChronosSystemFacade current resourcePathPrefix: 
 'C:\Documents and Settings\shibumi\My Documents\Squeak\Chronos'.

You can also ask Chronos to search for the time zone repository at various likely locations (as documented in the Chronos installation instructions) by evaluating the following "do it":


ChronosSystemFacade current resourceRepositoryContext invalidateResourcePaths

The #invalidateResourcePaths operation can be quite useful in VisualWorks, but much less so in Squeak. The VW infrastructure provides the basis for a rather sophisticated approach to finding a resource using a dynamically-determined "search path," compared to what can be easily implemented in Squeak. For this reason, I expect most Squeak users will simply keep the time zone repository in the same directory as their image file.

I would also note that the Chronos infrastructure for managing/accessing reference data had to be drastically refactored/redesigned in order to support this new functionality. One consequence of the refactoring/redesign is that a lot of the inter-Smalltalk "platform portability" code used by Chronos has been factored out into its own modules that are completely independent of the rest of Chronos.

I'll have much more to say about Chronos' "inter-Smalltalk portability" modules in the future. I have a suspicion that those modules might be of great interest to certain people who need to maintain versions of their applications on multiple Smalltalk platforms--Squeak, VisualWorks and Dophin, for example.

I'll also be providing full documentation of the Chronos reference data framework, including how to use it for your own reference data (whether or not you need or use Chronos date/time functionality.) But for now, you'll just have to wait.

In fact, it may be some time before there are any new versions of Chronos published. I have other matters to which I must attend--and I need a vacation. But I will continue to write blog entries.

--Alan

North American Time Zones Switch to Daylight Saving (Summer) Time

Labels: Chronos, educational, examples, Smalltalk

Did those of you living in North America remember to move your clocks ahead by one hour?

The Chronos Date/Time Library makes it easy to see the transition as it rolls from one time zone to the next. [Note: Most time zones transition to and from Daylight Saving Time at the same local time, not at the same moment in Universal Time. The major exceptions are the European time zones. All countries in the European Union transition at the same moment according to Universal Time, without regard to local time.]

Here's how Chronos shows the situation just before my local time zone switches to Daylight Saving Time:

Sun, 02 Apr 2006 21:55:02 +1200 (NZST: Pacific/Auckland | New Zealand Time)
Sun, 02 Apr 2006 19:55:02 +1000 (EST: Australia/Sydney | AUS Eastern Time)
Sun, 02 Apr 2006 18:55:02 +0900 (JST: Asia/Tokyo | Tokyo Time)
Sun, 02 Apr 2006 17:55:02 +0800 (WST: Australia/Perth | W. Australia Time)
Sun, 02 Apr 2006 17:55:02 +0800 (HKT: Asia/Hong_Kong)
Sun, 02 Apr 2006 15:25:02 +0530 (IST: Asia/Calcutta | India Time)
Sun, 02 Apr 2006 13:55:02 +0400 (MSD: Europe/Moscow | Russian Time)
Sun, 02 Apr 2006 12:55:02 +0300 (IDT: Asia/Jerusalem | Israel Time)
Sun, 02 Apr 2006 11:55:02 +0200 (CEST: Europe/Amsterdam)
Sun, 02 Apr 2006 10:55:02 +0100 (BST: Europe/London | London Time)
Sun, 02 Apr 2006 09:55:02 +0000 (UT: Universal Time)
Sun, 02 Apr 2006 06:55:02 -0300 (BRT: America/Sao_Paulo | E. South America Time)
Sun, 02 Apr 2006 06:55:02 -0300 (ART: America/Argentina/Buenos_Aires)
Sun, 02 Apr 2006 05:55:02 -0400 (EDT: America/New_York | Eastern Time)
Sun, 02 Apr 2006 04:55:02 -0500 (CDT: America/Chicago | Central Time)
Sun, 02 Apr 2006 03:55:02 -0600 (MDT: America/Denver | Mountain Time)
Sun, 02 Apr 2006 01:55:02 -0800 (PST: America/Los_Angeles | Pacific Time)
Sat, 01 Apr 2006 23:55:02 -1000 (HST: Pacific/Honolulu | Hawaiian Time)

Note that most of the other North American time zones have already switched as of the time shown above. For example, New York is usually 3 hours ahead of California, but at the moment depicted in the above it is 4 hours ahead.

And here's the situation as of the moment of transition:

Sun, 02 Apr 2006 22:00:00 +1200 (NZST: Pacific/Auckland | New Zealand Time)
Sun, 02 Apr 2006 20:00:00 +1000 (EST: Australia/Sydney | AUS Eastern Time)
Sun, 02 Apr 2006 19:00:00 +0900 (JST: Asia/Tokyo | Tokyo Time)
Sun, 02 Apr 2006 18:00:00 +0800 (WST: Australia/Perth | W. Australia Time)
Sun, 02 Apr 2006 18:00:00 +0800 (HKT: Asia/Hong_Kong)
Sun, 02 Apr 2006 15:30:00 +0530 (IST: Asia/Calcutta | India Time)
Sun, 02 Apr 2006 14:00:00 +0400 (MSD: Europe/Moscow | Russian Time)
Sun, 02 Apr 2006 13:00:00 +0300 (IDT: Asia/Jerusalem | Israel Time)
Sun, 02 Apr 2006 12:00:00 +0200 (CEST: Europe/Amsterdam)
Sun, 02 Apr 2006 11:00:00 +0100 (BST: Europe/London | London Time)
Sun, 02 Apr 2006 10:00:00 +0000 (UT: Universal Time)
Sun, 02 Apr 2006 07:00:00 -0300 (BRT: America/Sao_Paulo | E. South America Time)
Sun, 02 Apr 2006 07:00:00 -0300 (ART: America/Argentina/Buenos_Aires)
Sun, 02 Apr 2006 06:00:00 -0400 (EDT: America/New_York | Eastern Time)
Sun, 02 Apr 2006 05:00:00 -0500 (CDT: America/Chicago | Central Time)
Sun, 02 Apr 2006 04:00:00 -0600 (MDT: America/Denver | Mountain Time)
Sun, 02 Apr 2006 03:00:00 -0700 (PDT: America/Los_Angeles | Pacific Time)
Sun, 02 Apr 2006 00:00:00 -1000 (HST: Pacific/Honolulu | Hawaiian Time)

The offset of America/Los_Angeles is now -7 hours, instead of -8 hours--and the New York time zone is again only 3 hours ahead of San Francisco's.