To be simple and straight to the point: why

format_date(1238536800, 'custom', 'Y-m-d');

and

date('Y-m-d', 1238536800);

have different results? First one is 2009-03-31 (which is wrong), second one is 2009-04-01 (which is right). How can I ensure that my Drupal 6 (working in CET at the moment) displays the unix_timestamps happening to be in CEST properly with format_date(), too? (And I think I would have something like this vice versa.)
Or I should simply forget using Drupal's format_date() when displaying dates, and simply use PHP's date()?

Besides the answers I am interested in the arguments as well.

Comments

peterx’s picture

Go to http://api.drupal.org/api, select Drupal 6, then search for format_date. You will find the actual code that performs the work. The difference might be time zones or daylight savings time or some hack to world time by NASA, Klaatu, Microsoft, or George Bush. Well, perhaps not Klaatu or NASA.

petermoulding.com/web_architect

boobaa’s picture

http://api.drupal.org/api/function/format_date/6 is open here in a tab of mine. As I am not an expert of those pesky DST/non-DST stuff, nor I know the arguments that the author(s) of format_date() had in mind, I just wondered why Drupal messes up a thing that PHP handles right. OK, you may say that it is "right for me", but not "right for the Drupal masses", but anyway: if Drupal has a format_date(), why do I have to use a custom function of mine with almost the same functionality - just to cover a bug? feature? in Drupal?

OTOH I have been informed that this DST stuff is fixed in HEAD of Drupal 7 - which is still a moving target for poor module developers like me - and it looks like it is/was one of the most outstanding bug? feature? of Drupal with its ~4.5 years lifespan...

peterx’s picture

PHP handles the general case where a Web site is is set up for one location and one time zone. Consider a Drupal multisite configuration with each site set up for a different country and language. Drupal tries to split out the month name and translate the month name to the local language. Drupal also tries to translate the three letter abbreviations, day names, and am/pm. Within each site you could also have add on modules to let users specify their own time zone or language.

Daylight savings is fun. In Australia, some states are larger than most countries. In some towns in the middle of Australia, people use the time zone of the radio station they listen to, and you can have half the town listening to a station in a different time zone. Then some states use daylight saving time while others do not. At one stage we had several states introduce the same daylight saving time shift but with all states starting and ending in different weeks.

petermoulding.com/web_architect

fossie’s picture

It's very nice that drupal handles nicely the locals etc., but the result should be right.

I've set timezone, language, ... (drupal 5.15)

I don't know what causing the problem, but in a node-content_type.tpl.php file I want to use:

$my_date = strtotime($node->field_date[0]['value']); 
print format_date($my_date, 'custom', 'D d F Y'); 
print date('D d F Y', $my_date); 

results in two different dates.

Why is the function causing the difference?

TIA,
Fossie

fossie’s picture

Found a workaround:

http://drupal.org/node/187449

    $my_date = strtotime($node->field_date[0]['value']); 
    $tz_offset = strtotime(date("M d Y H:i:s")) - strtotime(gmdate("M d Y H:i:s"));
    $my_date += $tz_offset;
    print format_date($my_date, 'custom', 'D d F Y', NULL); 

Seems to fix the problem.

HTH,
Fossie

jlund’s picture

This worked for me too, thanks!

codybarr’s picture

This was really helpful. Thank you.

johnhanley’s picture

Props to @fossie.

I wracked my brain for an hour trying to figure out why format_date wasn't calculating timezones correctly.

I can't believe the timestamp has to be massaged before calling format_date(). I thought that was suppose to be one of the main reasons for using it versus PHP date.

hongpong’s picture

I had to use your workaround on a D7 code snippet someone foisteed on us. wow

alanpeart’s picture

This workaround saved my sanity, thanks. I can't understand why this should be necessary but I tried everything to do with settings on the server/drupal installation and this was the only thing that worked.

Technical Director at The Creative Coop

http://www.creative.coop