This post originated from an RSS feed registered with Ruby Buzz by Red Handed. Original Post: Showing Perfect Time Feed Title: RedHanded Feed URL: http://redhanded.hobix.com/index.xml Feed Description: sneaking Ruby through the system Latest Ruby Buzz Posts Latest Ruby Buzz Posts by Red Handed Latest Posts From RedHanded

What timezone do your site’s timestamps show? Or have you opted to just say three months ago? Or you could offer the user a timezone setting, right? These are tough issues, with a worldwide audience which could be anywhere and a server which could end up moving anywhere as well.

Hold up. Before you start writing anything, ecmanaut has a very convincing rant on not interfering at all. Just pass UNIX time straight out of the database and format the time in Javascript. (Read his article and trounce back here for the slight Ruby code.)

Pitching Timestamps to Javascript

Can’t you see your web framework abstracting this away nicely?

  Posted by  on 

I’ve added this in Hoodwink’d like so:

 def js_time( unixt, fmt = "%d %b %Y at %I:%M:%S %p" )
   %{
      
      
        #{Time.at(unixt.to_i).strftime(fmt)}
      
   }
 end

This method takes a unix timestamp and writes out a script tag which will format the date according to the user’s locale. If no Javascript is available, time according to the server’s timezone will be reported.

Unity of Time Formatting

This is also dependant upon a Javascript version of Ruby’s own strftime.

 /* strftime formats */
 var strftime_funks = {
   zeropad: function( n ){ return n>9 ? n : '0'+n; },
   a: function(t) { return ['Sun','Mon','Tue','Wed',
      'Thu','Fri','Sat'][t.getDay()] },
   A: function(t) { return ['Sunday','Monday','Tuedsay',
      'Wednesday','Thursday','Friday','Saturday'][t.getDay()] },
   b: function(t) { return ['Jan','Feb','Mar','Apr',
      'May','Jun', 'Jul','Aug','Sep','Oct','Nov','Dec'
      ][t.getMonth()] },
   B: function(t) { return ['January','February','March','April',
      'May','June', 'July','August','September','October',
      'November','December'][t.getMonth()] },
   c: function(t) { return t.toString() },
   d: function(t) { return this.zeropad(t.getDate()) },
   H: function(t) { return this.zeropad(t.getHours()) },
   I: function(t) { return this.zeropad((t.getHours() + 12) % 12) },
   m: function(t) { return this.zeropad(t.getMonth()+1) }, // month-1
   M: function(t) { return this.zeropad(t.getMinutes()) },
   p: function(t) { return this.H(t) < 12 ? 'AM' : 'PM'; },
   S: function(t) { return this.zeropad(t.getSeconds()) },
   w: function(t) { return t.getDay() }, // 0..6 == sun..sat
   y: function(t) { return this.zeropad(this.Y(t) % 100); },
   Y: function(t) { return t.getFullYear() },
  '%': function(t) { return '%' }
 };

 Date.prototype.strftime = function (fmt) {
   var t = this;
   return fmt.replace(/%([A-Za-z%]+)/g, 
     function (str, p1, offset, s) {
       if (strftime_funks[p1]) return strftime_funks[p1](t);
       else                    return p1;
     });
 };

The Best?

Is this the best option? Is this even a good option? Obviously, the biggest weakness is whether your users’ clocks are right or not. Still, the time will appear relative to their computer’s time—you’re just going along with the illusion. I think you also have to wonder if Javascript is on or not. With Hoodwink’d, users have to use Javascript. Even the MouseHole version requires it.

I buy ecmanaut’s argument completely, along with his recommendation for backing it all up with a timezone selector.

As you are pioneering this field of end-user usability, you may want to state that times and dates are indeed given in the visitor’s frame of reference, as people have generally come to expect to see times given in some random and hence typically fairly useless time zone. This can be seen as a not entirely bad reason for actually providing a time zone configuration option, should you want one. I would suggest defaulting it to “auto” or “local time” using the above method, though, as that is most likely what the user would want to see, anyway. This way, the configuration option actually doubles as documentation of what times the site shows, in a place a visitor is likely to look for it. To make it extra apparent that you render proper times, you might equip the page with the setting with a printout of present time, which the visitor will easily recognize as the time her computer clock shows (since they are in fact one and the same).