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

Geboorte

Vandaag is een bijzondere dag. Voor mij dan, want voor 't eerst een blog begonnen.

Bloggen om 't bloggen? Geloof 't maar niet.  Het gaat om een technische kennismaking met de blog & google api's. En dan is het handig om je eigen blog te hebben.