tag -> FixI was frustrated that when I tried to reduce the font size on our home page with CSS, it didn't work.  I had tried a bunch of things, using percent, "em" units, pixels, etc.  This was a problem in both IE and Firefox.  I had even tried using the FireBug plugin to debug it.It turns out that content inside of tables, which is all of the content on our home page, is set by the font-size for tbody, vs. body.  Oddly, the other attributes such as font-family and color can be set just in body, but size must be set for tbody.So this will give you red text, but will NOT reduce the size of content in tables:body {    color: #80000;    font-size: 0.9em;}But this fixes the problem:body, tbody {color: #80000;font-size: 0.9em;}I haven't seen an explanation for this online yet, and it seems very specific to the size directive, and had the same problem in two completely different browsers.  Weird.Posted at 06:20 PM in Web/Tech  | Permalink|Comments (0)|TrackBack (0)June 07, 2008PHP and Julian Dates prior to 1970, UnixToJD() with negative numbers, etc.First a quick review:  PHP can convert strings into numbers with the handy this handy function:$secs = strtotime( "June 18, 2008" );This will give you an integer representing the number of seconds since January 1st, 1970 (actually, just before midnight December 31st, 1969), referred to as the Unix epoch.Then you can convert this from seconds into a Julian Date / Julian Day with the PHP function UnixToJD().  The absolute value of this second number is very helpful, it'll be over 2 million, but you can reliably subtract two Julian dates to get the number of days between them.$jd = UnixToJD( $secs );Now for the problem, what about dates prior to 1970?  This is where things partially break, but there is a workaround (at least for dates > 1901).First the good news, strtotime STILL WORKS, so you can do:$negativeSecs = strtotime( "June 18, 1964" );And you'll get a big negative number, which is fine.But this breaks:$jd2 = UnixToJD( $negativeSecs );You will always get the same date back, effectively UnixToJD( 0 );But the Julian date range extends way earlier than 1970, more than 2 million days earlier.  So the above date in 1964 DOES have a valid, positive Julian day associated with it.Now for the workaround:Convert the Unix time, in seconds, into days by simply dividing by the number of seconds in a day, and either rounding off or truncating the value.  This is valid for both positive and negative dates.  I'll call this "Unix epoch days", the number of days since 1970, and for dates prior to 1970 it's just a negative value.Then just "add" the Unix days (which will be positive or negative) to the base Julian day for 1/1/1970.The only odd issue I've found is an "off by one" error caused by the timezone.  So if you use this method, try it with dates after 1970 first, and compare the results to using UnixToJD().And what is the base Julian day?  It's eit