Not that they do any real good for anything at the moment, but since I decided timezones were a blocking issue for "alerts", they got done. This is a bit bass-ackwards, but I eventually started with
http://laughingmeme.org/articles/2003/09/25/timezone-selectorThat's a bit of perl code that dumps the data from DateTime, DateTime::TimeZone, and/or DateTime::Locale -- into a nice little javascript selector box. I wanted to avoid the javascript so I hacked it to dump the regions/cities into a little php hash of arrays. Now I can play with it at my leisure, but for now it's a single select box with all the combinations. A bit long, but functional. Ideally, I'll add some behaviour tags to make it split the single select into a nifty combo select when javascript is available. Really, really not necessary though.
The DateTime perl module(s) use the near-canonical
Olson Database. Of course, using that whole crazy database just to get
This is my timehack. I know my server's Eastern, so that's the way all the data's gone into mysql, and that's how the data comes out. I don't want to go and change the data unless I absolutely have to, so...
well, it's kind of sad, but it appears to work. :)
function altertz($datetime,$timezone) {
if (empty($datetime)) return $datetime;
//we have something that is a datetime "assumed" to be correct,
//most likely coming from mysql, and we need to nudge it around.
//ICK!
//first, we set timezone to the 'real' timezone the data was created
//in. for writersplanner, that's "eastern"
$oldtz = getenv("TZ");
putenv("TZ=US/Eastern");
//then, turn our time into a unix stamp
$time = strtotime($datetime);
if (!$timezone) { $timezone = "GMT"; }
putenv("TZ=".$timezone);
$retval= date("Y-m-d H:i:s T",$time);
putenv("TZ=".$oldtz);
return $retval;
}
Of course, with all this, the only thing that's changed at the moment is ... display of account creation/validation/last login datetimes. But that's proof of concept, right? ;)