Forum: Typo Timezones

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
49ce8b6018b2cc3089f1ed3db6923a6d?d=identicon&s=25 Syed Uzair Aqeel (Guest)
on 2006-04-22 17:07
(Received via mailing list)
Y'know, it'd be nice if I could specify a time offset in the admin
interface
so that my blog lived in the same timezone as me. I host with DreamHost,
which is currently in PDT, whereas I'm in the UK. I know blog clients
like
Ecto (http://ecto.kung-foo.tv) allow one to set an offset, but I
normally
use either the Admin interface or the Performancing extension
(http://performancing.com/) to post, and neither of those have a similar
option. (To be fair, if you're not doing a 'Quick Post' one can adjust
the
time of publishing manually in the Admin interface, but it's tedious
doing
this for each blog entry).

I suspect this would be a fairly simple fix, so I'll try throwing my
creaky
Ruby skillz at it.

Uzair
04d072ab8843cfd3d1714faf3a2a0fb2?d=identicon&s=25 mathew (Guest)
on 2006-04-22 18:08
(Received via mailing list)
Syed Uzair Aqeel 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, (c) 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
49ce8b6018b2cc3089f1ed3db6923a6d?d=identicon&s=25 Syed Uzair Aqeel (Guest)
on 2006-04-22 18:46
(Received via mailing list)
Ahem, I hope you don't get elected any time soon then. I regularly
shuttle
between 4 timezones, and UTC would have me perpetually confused :)

> 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.

I don't think I've fully understood what you meant with the
'discontinuity
in what they mean' bit, but I think this would be a generally acceptable
scheme. If I'm not in my regular timezone, I certainly don't want the
displayed timestamps for all my old posts to be recomputed in terms of
my
current timezone. I just want the next post to have the right timestamp
with
respect to where I am right now. Perhaps you can explain what you meant?

As a compromise, how about storing time in UTC and the offset in use
when
the entry was posted? Or, more acceptable, the timezone code, eg.
CST/EST/PDT.

Also, an aside: one could use Date.GetTimezoneOffset() to figure out
which
timezone the user is writing from. I wouldn't be in favour of this
myself,
since it wouldn't be transparent.

Cheers,

Uzair
D6f24842b973de6cb75203c4c57dfbcb?d=identicon&s=25 Gary Shewan (Guest)
on 2006-04-23 12:28
(Received via mailing list)
On 22 Apr 2006, at 17:42, Syed Uzair Aqeel wrote:
>
> As a compromise, how about storing time in UTC and the offset in
> use when
> the entry was posted? Or, more acceptable, the timezone code, eg.
> CST/EST/PDT.

You should write a userstory about this on the wiki Syed.  It
certainly seems trickier than I would have guessed.  It's a legacy
issue because Typo was originally conceived to only work with the
likes of Ecto and Marsedit ... and eh, the Windows equivalents.  The
admin interface was a later addition.

Gary
0196ff65610046d2f8ba58bc4a45f144?d=identicon&s=25 Piers Cawley (Guest)
on 2006-04-23 20:40
(Received via mailing list)
"Syed Uzair Aqeel" <uzair@nairang.org> writes:
> As a compromise, how about storing time in UTC and the offset in use when
> the entry was posted? Or, more acceptable, the timezone code, eg.
> CST/EST/PDT.

Time's a minefield and Timzone codes doubly so. It turns out they're
not unique. One of Perl's wins is the work that Dave Rolsky did on
the DateTime library (to the extent that every time I work with dates
in Ruby I find myself wishing someone had ported DateTime).  I'm all
for stashing everything in GMT though.

However, it's not something I'm going to lose any sleep over fixing;
I'm happy enough with our delta based time reporting for comments and
the likes. So long as articles are displayed in chronological order
I'm pretty happy. Your mileage may vary of course, so patches are
welcome.
0f9afa99528cbae28c6b6093fa5d0ebf?d=identicon&s=25 George Sudarkoff (Guest)
on 2006-04-23 21:11
(Received via mailing list)
Storing time in UTC and not storing anything else makes perfect sence
(to
me) for two reasons. First, because UTC never changes. Second, because
if we
want to be really smart about it, we should display the time in the time
zone of the _reader_.

But really, as it's all oh so badly messed up in our heads (if you have
relatives or friends you call often on the other side of the planet, you
know what I'm talking about), as far as the relative order of articles
and
comments is preserved nothing else really matters all that much.
42b570f6f4312a872c2fc671e3ddc82b?d=identicon&s=25 Trejkaz (Guest)
on 2006-04-24 13:25
(Received via mailing list)
On Sunday 23 April 2006 02:06, mathew wrote:
> 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.

You would store all times in UTC no matter what, so that when the user
changes
timezone, the application doesn't have to change every single database
entry.
No problem.

TX
04d072ab8843cfd3d1714faf3a2a0fb2?d=identicon&s=25 mathew (Guest)
on 2006-04-24 17:03
(Received via mailing list)
Trejkaz wrote:
> On Sunday 23 April 2006 02:06, mathew wrote:
>
>> 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.
>>
>
> You would store all times in UTC no matter what, so that when the user changes
> timezone, the application doesn't have to change every single database entry.
> No problem.

Read the rest of the e-mail, where I consider that possibility and point
out the problems it has.


mathew
0196ff65610046d2f8ba58bc4a45f144?d=identicon&s=25 Piers Cawley (Guest)
on 2006-04-24 22:51
(Received via mailing list)
mathew <meta@pobox.com> writes:
> [a long explanation of why times and dates are hard]

As soon as someone ports perl's DateTime[1] (which solves all mathew's
issues and more; mathew forgot to mention leap seconds, time deltas
where daylight savings is switching over and, oh, a bunch of other
stuff) I'll happily switch to using it for Typo's dates. Until that
happy day, I'll live with stashing everything as GMT (which may well
not be what we do now, but patches welcome) and displaying with simple
time deltas.

1. http://datetime.perl.org/
42b570f6f4312a872c2fc671e3ddc82b?d=identicon&s=25 Trejkaz (Guest)
on 2006-04-25 05:24
(Received via mailing list)
On Tuesday 25 April 2006 01:01, mathew wrote:
> Read the rest of the e-mail, where I consider that possibility and point
> out the problems it has.

There is a sum total of one problem with storing times in UTC, and that
is the
question of what to do when a single user posts from multiple timezones.

TX
04d072ab8843cfd3d1714faf3a2a0fb2?d=identicon&s=25 mathew (Guest)
on 2006-04-25 05:48
(Received via mailing list)
Trejkaz wrote:
> On Tuesday 25 April 2006 01:01, mathew wrote:
>
>> Read the rest of the e-mail, where I consider that possibility and point
>> out the problems it has.
>>
>
> There is a sum total of one problem with storing times in UTC, and that is the
> question of what to do when a single user posts from multiple timezones.

No, that's not a problem. The problem is how to display the information.
Generally speaking, you want it to be in a time zone that makes sense to
users, which means you need user preferences. Even if you default to a
specific time zone, you still have the issue of DST; see previous
discussion.

(Unless you're someone like me, in which case you'll happily put the
info in ISO 8601 format in UTC and let the users learn to like it.)


mathew
Dc3f3775a7d03ba1be8958aaee881d6b?d=identicon&s=25 Scott Laird (Guest)
on 2006-04-25 06:56
(Received via mailing list)
On 4/24/06, mathew <meta@pobox.com> wrote:> Trejkaz wrote:> > On Tuesday
25 April 2006 01:01, mathew wrote:> >> >> Read the rest of the e-mail,
where I consider that possibility and point> >> out the problems it
has.> >>> >> > There is a sum total of one problem with storing times in
UTC, and that is the> > question of what to do when a single user posts
from multiple timezones.>> No, that's not a problem. The problem is how
to display the information.> Generally speaking, you want it to be in a
time zone that makes sense to> users, which means you need user
preferences. Even if you default to a> specific time zone, you still
have the issue of DST; see previous> discussion.>> (Unless you're
someone like me, in which case you'll happily put the> info in ISO 8601
format in UTC and let the users learn to like it.)
Or we could put it into the HTML is UTC and let the Javascriptreformat
it to local time for readers.  Oh, wait--don't we already dothat?

Scott
04d072ab8843cfd3d1714faf3a2a0fb2?d=identicon&s=25 mathew (Guest)
on 2006-04-25 20:25
(Received via mailing list)
Scott Laird wrote:
> Or we could put it into the HTML is UTC and let the Javascriptreformat it to local time 
for readers.  Oh, wait--don't we already dothat?

Not on my version of trunk. I get the data stored as local-to-the-server
time in the database, and reported in the server time zone on pages.


mathew
42b570f6f4312a872c2fc671e3ddc82b?d=identicon&s=25 Trejkaz (Guest)
on 2006-04-26 15:13
(Received via mailing list)
On Tuesday 25 April 2006 13:46, mathew wrote:
> No, that's not a problem. The problem is how to display the information.
> Generally speaking, you want it to be in a time zone that makes sense to
> users, which means you need user preferences. Even if you default to a
> specific time zone, you still have the issue of DST; see previous
> discussion.

Funnily enough, Typo already says dates like "4 days ago" to the actual
user.

That is, unless you're talking about something in the admin interfaces.
But
user preferences wouldn't be a stretch in the admin preferences, as we
already have email and Jabber ID in there.

TX
04d072ab8843cfd3d1714faf3a2a0fb2?d=identicon&s=25 mathew (Guest)
on 2006-08-03 14:22
(Received via mailing list)
FWIW, I agree that storing everything as UTC is the best option in the
immediate future.

As I mentioned, I'd have taken that route myself, if it hadn't required
code changes.


mathew
Dc3f3775a7d03ba1be8958aaee881d6b?d=identicon&s=25 Scott Laird (Guest)
on 2006-08-03 14:22
(Received via mailing list)
Shouldn't running dispatch.fcgi with TZ=UTC solve this without code
changes?

Scott
On 4/24/06, mathew <meta@pobox.com> wrote:> FWIW, I agree that storing
everything as UTC is the best option in the> immediate future.>> As I
mentioned, I'd have taken that route myself, if it hadn't required> code
changes.>>> mathew> _______________________________________________>
Typo-list mailing list> Typo-list@rubyforge.org>
http://rubyforge.org/mailman/listinfo/typo-list>
04d072ab8843cfd3d1714faf3a2a0fb2?d=identicon&s=25 mathew (Guest)
on 2006-08-03 14:22
(Received via mailing list)
Scott Laird wrote:
> Shouldn't running dispatch.fcgi with TZ=UTC solve this without code changes?
>

You're right, at least as far as storing the data. So that just leaves
the idea of having an admin preference for how to adjust UTC for
display...


mathew
[ Why didn't I think of that? ]
49ce8b6018b2cc3089f1ed3db6923a6d?d=identicon&s=25 unknown (Guest)
on 2006-08-03 14:22
(Received via mailing list)
I really like this -- unfortunately it didn't seem to work when I tried
it
with WEBrick. I'm going to give it another go tonight. I did:

1. Kill lighttpd
2. export TZ=UTC (I run bash)
3. Start lighttpd

Does that sound right?

Thanks,

Uzair
49ce8b6018b2cc3089f1ed3db6923a6d?d=identicon&s=25 unknown (Guest)
on 2006-08-03 14:22
(Received via mailing list)
Bah, I meant "I'm going to do"...anyway, that's pretty much what I did
with WEBrick this morning (except I didn't already have an instance
running).

U.
59528506e6297141161afcde91d677c9?d=identicon&s=25 Nicolai Reuschling (codeblogger)
on 2006-08-03 14:22
(Received via mailing list)
2006/4/24, mathew <meta@pobox.com>:
>
> FWIW, I agree that storing everything as UTC is the best option in the
> immediate future.
>
>
Gnah, precise time is overrated.
This topic is locked and can not be replied to.