Syed Uzair A. wrote:
I suspect this would be a fairly simple fix, so I’ll try throwing my creaky
Ruby skillz at it.
It’s a lot less simple than it looks, because the underlying database
doesn’t have any time zone information, at least if you use the standard
schemas provided. I’ve written calendar software, so I’m acutely aware
of how many pitfalls there are.
Suppose you start with a simple admin preference for time zone. So, now
you know the user’s time zone is -0600. Now you’re faced with the
problem of what to actually store in the database.
Initially, you leave the code as is. The time and date for creation and
modification are added by Rails, in the server’s time zone. You simply
adjust it to/from the user’s time zone for web pages and forms, by using
the preference time zone, and the server’s time zone.
Then you think: what if your web host has a problem or raises its
prices, and you move to a different host? Or what happens when you move
to a different time zone? Suddenly all the dates and times for stuff
posted before you move will apparently change, relative to things posted
after you move. You’ll have to run through the entire database, changing
the date and time stamps from the old server’s time zone to the new
server’s time zone. Or if you move, you’ll need to compute the
difference between your old time zone and the server’s time zone,
compare that to the difference between your new time zone and the
server’s time zone, and use the difference between those values to
process all your existing data.
OK, that’s not good. So, what if you use the preference to adjust the
time on the form, but then store the adjusted time, in the user’s time
zone at the time of the posting? Time on form looks right, time on web
page looks right, even if you change hosts or move. End of problem yes?
Well, sorta. When you move the time stamps remain the same, but all
you’ve really done is hide the problem–now there’s a discontinuity in
what they mean. The web site will be showing dates and times in time
zone A before your move date, and in time zone B after your move date.
Depending on how often you move, this could get very confusing.
So you think a bit, and decide to store the date and time in a single
time zone for all eternity. The obvious choice is UTC. You adjust times
to and from UTC, based on the preference set in the admin interface.
Move to a new time zone? Data’s still all valid, just change the
preference and every page of the web site snaps to the new time zone.
Great.
Then autumn arrives, and you drop out of Daylight Saving Time. Oops.
Your post at 6pm in July now looks like you posted it at 5pm. So you
decide the right thing to do is to adjust automatically for DST. How
hard can that be, eh?
The answer is, pretty damn hard. Take my case, for example. My data set
goes back to 1987. Before 1997 I was in the UK, and during that time the
UK set its DST changeover dates by Act of Parliament, so they were
different from year to year. Then I moved to the US, for a different set
of DST changeover dates. Then the US passed a law changing its DST as of
next year. Luckily I didn’t live in parts of Indiana, or there would
have been times of my life when I didn’t observe DST at all. (As it was,
when I imported my data I passed each date/time stamp through an
algorithm that worked out missing time zones based on my personal
history.)
So, to adjust UTC times in the database for DST, you need a general
mechanism for specifying start date and end date of DST for all years
for which there is data, as the dates change from year to year.
If you’ve read this far, you may now understand why I modified the
schema I use to actually record the time zone for each entry. This at
least means my existing data remains intact, and new entries get
timestamped with enough information to let me locate them in time in the
future. All I need now is a way to use that information when generating
the pages…
The other option, of course, is to store and display everything in
UTC. I gave that some serious consideration too, but didn’t run with it
as it would have required that I make code changes to typo–whereas
changing the schema “just works” because of the magic of Rails.
So before you start hacking code, I’d suggest that you think about the
fact that (as I’ve explained above) UTC for storage and display is the
only really viable option, assuming (a) you want time stamps to have
consistent meaning on all pages of the site, (b) you don’t want to
reprocess your entire data set periodically, © you don’t want to store
time zone offsets in the database, and (d) you don’t want to deal with
the complexities of manual DST adjustment.
When I’m elected supreme ruler of the world, I will do away with time
zones and DST, and everyone will use UTC everywhere, on pain of
imprisonment. Until then, good luck.
mathew
