Why is there no way to specify alternate list-style-types?? You can specify alternate fonts in case a font isn't supported on the client, but you can't specify an alternate list marker. Frustrating! I wanted to use Hebrew or Chinese list markers, which work great in Mozilla, but IE defaults back to using plain numbers. I'd rather have a plain square instead of that, so I'm forced to use squares instead of cooler markers.
This is an update to my earlier post about storing times in MySQL.
1. Always store GMT
In your database tables you should always store the GMT/UTC (for the rest of this post I'll use "GMT") time, and you'll probably want to store the local time as well. For example, in my weblog entries table I have the following fields: Creation_DT, Creation_DT_GMT, Modification_DT, and Modification_DT_GMT. Those fields should be MySQL's DateTime field type. A scheme where you store the GMT time and some kind of time zone offset is not worth the trouble for the few bytes you'll save.
2. Don't depend on MySQL's timezone handling
Don't depend at all on MySQL's timezone handling. Depend completely on PHP's instead. Both PHP and MySQL respect the 'TZ' environment variable. However, while MySQL only pays attention to the TZ value when it starts up, PHP nicely lets you set it upon each request. Your operating system (unless it's Windows, I'm not sure what Windows does) most likely uses the tz database as its source for time zone data. Here's a handy reference card of all possible time zone values that should be valid for the TZ environment variable.
This means that you should never use MySQL's FROM_UNIXTIME or UNIX_TIMESTAMP functions because those depend on the time zone setting of your machine at the time MySQL started. Instead, always communicate with MySQL in the date format it expects, "YYYY-MM-DD HH:MM:SS" and have your code worry about what time zone those dates are in.
To set the TZ environment variable in PHP, use something like:
<?php putenv("TZ=US/Eastern");?>
That setting only lasts for the request, so don't worry about setting anything permanently.
Update: Here's documentation for Windows, and here are two pages with example settings. It appears they overlap, but it's not clear that not all time zone settings available on Unix are available on Windows.
3. Don't bother using PHP's gm* functions
Don't bother using PHP's gm* date functions. There's no need to. In your PHP code, make sure the TZ environment variable is set to the time zone you want and use date() for dealing with the request-specific localtime and then do date math using information you can get from date() (such as the 'Z' flag which gets you the time zone offset in seconds from GMT).
4. Utility Functions:
I have the following utility functions I use to do my all date handling:
<?php
function getGmt($time){return $time-date('Z',$time);}
function getGmtDiff($lt, $ut){return ($lt-$ut) / 3600;}
function getMysqlDate($timestamp){return date("Y-m-d", $timestamp);}
function getMysqlDatetime($timestamp){return date("Y-m-d H:i:s", $timestamp);}
function getTimestamp($mysql_datetime){return strtotime($mysql_datetime);}
?>
I hope it's fairly obvious what each function does. To show you how to use them, here's a snippet from the SQL I use to insert a weblog entry into my MySQL table:
INSERT INTO Weblog_Entries(... Creation_DT, Creation_DT_GMT ...) VALUES(
...'".getMysqlDatetime($t)."', '".getMysqlDatetime(getGmt($t))."',...)
Importantly, when you get the data out of the database, you don't need to do another conversion to or from GMT. However, as long as you only need to deal with dates in this epoch (1970-2038) you should always deal with dates and times as timestamps (32 bit integers) in your code. In other words, when you get your dates out of the database, convert them to timestamps as soon as possible using getTimestamp(). In my "weblog model" I do something like the following:
<?php
for($n=0,$c=count($entries); $n<$c; $n++){
$entries[$n]['cd'] = getTimestamp($entries[$n]['cd']);
$entries[$n]['cd_gmt'] = getTimestamp($entries[$n]['cd_gmt']);
# ... and so on
?>
getGmtDiff() gives you the difference in hours between GMT and PHP's localtime. You can see that in use directly below as the timestamp for this post will display "(utc-4)" as its time zone. getGmtDiff() is how I derive that -4. Here's the code I use to print that:
(utc<?php printf("%+d",getGmtDiff($cd, $cd_gmt))?>)
That doesn't account for if the difference contains a fraction of an hour, but that's ok for me for now.
5. How time() works in PHP
It's important to understand how PHP handles timestamps. PHP always uses the GMT time for its timestamps. In other words, when you say:
<?php $time = time()?>
The number stored in $time is the seconds since Jan 1, 1970 GMT. The other functions such as date() then adjust for your local time zone on each call. The only difference between date() and gmdate() is that gmdate() doesn't do the adjustment for your time zone.
Anyway, I hope this all helps save people time.
Update: I experienced some problems with this scheme when my server was in the middle of changing for daylight savings time. When I figure out the right way to fix this I'll make a note of it here.
Claudia Rosett at the Wall Street Journal is looking for signs of a Democratic foreign policy. But, they'd rather play the class warfare card while having radical Islamic imams speak at their convention.
This entire convention has been so vacuous that it's infuriating. I've been waiting to hear one policy committment by the Democrats besides "We're going to raise your taxes, and try to be nicer to France", and I'm still waiting. I really do hope Kerry's speech contains some actual ideas in it. I'd much rather be able to discuss actual policy than have to listen to a bunch of people talk about nothing.
I hate ASP.NET
I hate ASP... I was doing wonderswith PHP, then suddenly one of myclients...
Johnies: Mar 17, 6:14am