Eieren

Hier leg ik vandaag mijn ei.

Nog een prettige dag.

Unicode

I program, a lot. And do maths, a lot.

So, why is it that most programming languages still stick with ASCII while virtually all computing platforms now support UNICODE?  For example, Python, Javascript and Java (and all its derivatives) all support UNICODE strings as objects you can program with, but it is not possible to use UNICODE as function names or operators.

Tell me, which is visually and conceptually more appealing?:

if((a<=b) && ((x<y) || (b>=a)){ ...

or

if( a≤b ∧ (x<y ∨ b≥a)) {...

In the last example, you immediatly recognise that a≤b ≣ b≥a and write:

if( a≤b ∧ (x<y ∨ a≤b)) {...

And then, by the rule of absorption:

if( x<y ) {...

Okay, may be too simple an example to make an instant convert out of you. But the point I attempt to make is that using the traditional math notation makes it easier to recognise interesting patterns.
There is, however, this small issue of conditionals.  The mathematical meaning of ∨ and ∧ is not the same as the operational meaning of && and ||.  && is a conditional and and || is a conditional or. Speaking mathematically, it doesn't realy matter, but when using it in a programming language, it does matter.

Granted, we had APL, a programming language in which it was all too easy to abuse the conciseness of its operator syntax into abuse.  But there is no objection against a judicious use of, e.g. set operators in, say, SQL or with Python's set operations!  I'm willing to wager a bet that as soon as set expressions in programming languages are visually similar to their mathematical counterparts, programmers will be more interested in the mathematical side of sets.

With Mac OS X,  the relational operators are very easy to use: <, =, and > are accessible with a Shift-key, ≤, ≥, ≠, ¬ and Ø (which can very well double as an empty set) are accessible with an Alt-key.
To make it easy to use all others which are relevant to you, you can use TextExpander or snippets with TextMate. I bet that you can squeeze this functionality out of your favourite editor on any platform.

2 februari heb ik een functie laten zien die een ISO datetime string omzet naar een UTC-base Date. Maar helaas blijkt deze functie niet in alle browsers te werken. In Firefox 3.6.x blijkt dat de argumenten meegegeven aan Date.UTC per se Integers moeten zijn, terwijl er Strings worden aangegeven. Bovendien is het converteren van numerieke strings naar Integers met new Number(s) wat onhandig.


Eerst heb ik een method gemaakt voor Arrays, die een functie/method toepast op alle Array-elementen en een Array met de resultaten retourneert:


Array.prototype.map =function(f){
res =new Array();
for(var i=0; i<this.length; i++){
res.push(f(this[i]));
};
return res;
};


Met deze method is de functie toUTC aangepast. Omdat toUTC() alleen van toepassing is op Strings, heb ik er maar meteen een method voor het String-object van gemaakt (veranderingen zijn onderstreept):

String.prototype.toUTC function(utcdatestring){
var minutemillisecs =60*1000,
      re =new RegExp("([0-9]{4})-([0-9]{2})-([0-9]{2})T([0-9]{2}):([0-9]{2}):([0-9]{2})\.([0-9]{3})([+-])([0-9]{2}):([0-9]{2})","i"),
  m  =re.exec(utcdatestring),
      n  =m.map(parseInt),
  d = Date.UTC(n[1], n[2]-1, n[3], n[4], n[5], n[6], n[7]),
tz = parseInt(m[8] +"1") * ((60 * n[9]) + n[10]) * minutemillisecs,
return new Date(d - tz);
};


Het is aardig om te zien dat met een eenvoudige hulpfunctie/method bestaande code er meteen een stuk vriendelijker uit kan zien.

Buizenradios

Ik zet net mijn standalone internet radio aan en, zoals gewoonlijk, duurt een paar seconden duurt voordat het radiootje geluid geeft.


En dan dringt 't tot me door; de buizenradio, die ik 35 jaar geleden had, nam ook zijn tijd voor dat hij geluid gaf, maar alle radio's tussen deze en de internet radio gaven meteen geluid.


Je vraagt 't je wel af; wat is er in die tijd nu eigenlijk veranderd?

Hetgeen oplevert:

function toUTC(utcdatestring){
var minutemillisecs = 60*1000,
                    re = new RegExp("([0-9]{4})-([0-9]{2})-([0-9]{2})T([0-9]{2}):([0-9]{2}):([0-9]{2})\.([0-9]{3})([+-])([0-9]{2}):([0-9]{2})","i"),
  m  = re.exec(utcdatestring),
  d = Date.UTC(m[1], m[2]-1, m[3], m[4], m[5], m[6], m[7]),
  tz = (new Number(m[8] +"1")) * ((60 * new Number(m[9])) + new Number(m[10])) * minutemillisecs,
return new Date(d - tz);
}


Deze functie levert de UTC tijd op van een string zoals bijvoorbeeld 
       
        2011-02-06T17:31:00.001+01:00


En retourneert een Date-object met de UTC tijd volgens deze tijd.


Een aardige aanvulling op de functionaliteit van het Date-object.

Aha!

Dat is dus duidelijk.


Het publish-element rapporteert mét timezone informatie:

<published>2011-02-06T07:33:00.001-08:00</published>

Nu was mijn lokale tijd 16:33 toen het bericht verzonden werd.


 07:33:00.001 in time zone -08:00 naar UTC is dus er (modulo 24) -8  van aftrekken : 15:33:00.001


En in Nederland zit je in time zone +01:00 en het is dan bij UTC 15:33 hier 16:33 lokale tijd.


-8:00 is in de USA pacific time.  Waarschijnlijk "leeft" daar ergens de server de "google-time" bij houdt.


c'est tout

UTC of local time?

Ik vraag mij af of de blog in de feeds de UTC tijd of de lokale tijd bijhoudt.

Het experiment is uiterst simpel:
1. Maak een nieuwe blog entry aan nu en noteer de (lokale) tijd.
2. En kijk wat de feed op levert in het  published-element.

Keep u posted