Looks like the time zone code is broke. August 31, 2006 8:34 PM Subscribe
Looks like the time zone code is broke. Everything is showing up PST for me, even though I've got Eastern set.
Everything's showing up EST to me. In fact, I thought I remembered that there are parts of MeFi that are stuck on PST all the time, no matter what your preference, but I either remember wrong or that bug's been fixed. Are you sure your preferences are set correctly?
posted by amro at 8:41 PM on August 31, 2006
posted by amro at 8:41 PM on August 31, 2006
Everything is still showing up in my timezone, AKST.
posted by rhapsodie at 9:08 PM on August 31, 2006
posted by rhapsodie at 9:08 PM on August 31, 2006
The opposite: your time zone cookie got lost. Go to your preferences and set it again, and it should create a new cookie.
posted by Plutor at 3:45 AM on September 1, 2006
posted by Plutor at 3:45 AM on September 1, 2006
I'm slightly confused, my clock says GMT but it says the right time for British Summer Time which is what I'm actually in.
posted by biffa at 3:58 AM on September 1, 2006
posted by biffa at 3:58 AM on September 1, 2006
intermod, biffa: You guys missed the DST hackiness bitching last week. I think that essentially, Matt adds an hour to everyone's timezone during US daylight saving time, and since that's very close to the same as BST, it's Good Enough™.
posted by Plutor at 4:40 AM on September 1, 2006
posted by Plutor at 4:40 AM on September 1, 2006
Twice -- over a year ago and again last week -- I've outlined database fixes for timezones, in the form of a database timezone conversion lookup table.
That would have fixed timezones for all users.
mathowie replied "Timezones are a bitch. This is a hack. It works good enough for most people but isn't perfect. I don't lose sleep over it."
Then I offered portable C code, (essentially) conformant to the POSIX TZ.2 format, and not reliant on any time or timezone library.
No interest in that either.
So it looks like matt's not interested in fixing this; if you are, do what I did: I wrote a Greasemonkey script that fixes the incorrect timezones, and now I see correct timezones. So if you want to see correct timezones, write yourself a script.
posted by orthogonality at 5:05 AM on September 1, 2006 [1 favorite]
That would have fixed timezones for all users.
mathowie replied "Timezones are a bitch. This is a hack. It works good enough for most people but isn't perfect. I don't lose sleep over it."
Then I offered portable C code, (essentially) conformant to the POSIX TZ.2 format, and not reliant on any time or timezone library.
No interest in that either.
So it looks like matt's not interested in fixing this; if you are, do what I did: I wrote a Greasemonkey script that fixes the incorrect timezones, and now I see correct timezones. So if you want to see correct timezones, write yourself a script.
posted by orthogonality at 5:05 AM on September 1, 2006 [1 favorite]
ortho: The operative word (if you will) being "C". I have no way of being sure, but I'd imagine integrating your code into CF would be non-trivial.
posted by Plutor at 5:18 AM on September 1, 2006 [1 favorite]
posted by Plutor at 5:18 AM on September 1, 2006 [1 favorite]
Thanks for the reminder, now that the contest is over I can set my timezone back to EST.
posted by jessamyn (staff) at 5:23 AM on September 1, 2006
posted by jessamyn (staff) at 5:23 AM on September 1, 2006
Cold fusion runs in the JVM, so I would imagine to integrate C code you would first have to write java native class, which is not impossible but you do need to know java to do it.
posted by delmoi at 5:32 AM on September 1, 2006
posted by delmoi at 5:32 AM on September 1, 2006
So it looks like matt's not interested in fixing this
The server is sitting in the us, running on pacific time, as it has been for 7 years now. It's not exactly trouble-free to switch to GMT and expect everything in the past to work.
I've seen two projects' innards with perfect timezone stuff and it's freaking crazy for just a stupid timestamp. There are something like 292 different timezones and daylight saving shifts worldwide including all the half hour off ones and all the dates for when each country (and state within) decides to switch time (or not). Plus, it changes all the time (aren't we moving it a few weeks in each direction next year in the US?).
I don't see how the fixes you propose cover every little state rule within India and Indiana (within the single state there is one timezone doing DST, then another that doesn't want DST).
It's an 80/20 thing here. I can make 80% of everyone happy with some simple offsets from the server's time. Getting the last 20% correct starts looking like a full time job when you dive into every stupid exception and time law around the world.
posted by mathowie (staff) at 7:13 AM on September 1, 2006
The server is sitting in the us, running on pacific time, as it has been for 7 years now. It's not exactly trouble-free to switch to GMT and expect everything in the past to work.
I've seen two projects' innards with perfect timezone stuff and it's freaking crazy for just a stupid timestamp. There are something like 292 different timezones and daylight saving shifts worldwide including all the half hour off ones and all the dates for when each country (and state within) decides to switch time (or not). Plus, it changes all the time (aren't we moving it a few weeks in each direction next year in the US?).
I don't see how the fixes you propose cover every little state rule within India and Indiana (within the single state there is one timezone doing DST, then another that doesn't want DST).
It's an 80/20 thing here. I can make 80% of everyone happy with some simple offsets from the server's time. Getting the last 20% correct starts looking like a full time job when you dive into every stupid exception and time law around the world.
posted by mathowie (staff) at 7:13 AM on September 1, 2006
time to sell the computer, ortho, and BUY A WATCH.
posted by quonsar at 7:44 AM on September 1, 2006 [1 favorite]
posted by quonsar at 7:44 AM on September 1, 2006 [1 favorite]
Time is an illusion...
posted by Fidel Cashflow at 7:50 AM on September 1, 2006
posted by Fidel Cashflow at 7:50 AM on September 1, 2006
mathowie writes "I've seen two projects' innards with perfect timezone stuff and it's freaking crazy for just a stupid timestamp. There are something like 292 different timezones and daylight saving shifts worldwide including all the half hour off ones and all the dates for when each country (and state within) decides to switch time (or not). Plus, it changes all the time (aren't we moving it a few weeks in each direction next year in the US?)."
You're absolutely right Matt. There are a bunch of timezones, some not whole-hour, some with DST, some without, all with different start and end times most of which aren't Julian dates, and it changes at the fiat of legislatures. 292 is the lower-bound; add in future timezones and it probably doubles.
But you've got what, 20,000 users, each with a bunch of different preference settings and comments and posts and favorites. How do you handle all that? With lots of rows in tables in a database.
You could handle all 292 timezones, including Indiana and plus the new 2007 US DST, and Gujarat and Moldova and Mongolia, with rows in a table. And the database doesn't just store data; it calculates too. So you could do all the calculations in the database, so you wouldn't have to write or maintain Cold Fusion code for the timezones. This sort of thing is what databases are really for.
Of course, once a year or so you'd have to add new timezones to your database, but once a year now you have to explain why you don't, so that's a wash. And setting it up it would be a fun project for you to do; you'd get to learn to exploit the full capabilities of your database, and that real sense of satisfaction from crafting something reasonably complex that works just so. Sort of like building a watch, with all the little gears and springs and jewels. There's a beauty in that that goes beyond mere utility.
posted by orthogonality at 8:41 AM on September 1, 2006
You're absolutely right Matt. There are a bunch of timezones, some not whole-hour, some with DST, some without, all with different start and end times most of which aren't Julian dates, and it changes at the fiat of legislatures. 292 is the lower-bound; add in future timezones and it probably doubles.
But you've got what, 20,000 users, each with a bunch of different preference settings and comments and posts and favorites. How do you handle all that? With lots of rows in tables in a database.
You could handle all 292 timezones, including Indiana and plus the new 2007 US DST, and Gujarat and Moldova and Mongolia, with rows in a table. And the database doesn't just store data; it calculates too. So you could do all the calculations in the database, so you wouldn't have to write or maintain Cold Fusion code for the timezones. This sort of thing is what databases are really for.
Of course, once a year or so you'd have to add new timezones to your database, but once a year now you have to explain why you don't, so that's a wash. And setting it up it would be a fun project for you to do; you'd get to learn to exploit the full capabilities of your database, and that real sense of satisfaction from crafting something reasonably complex that works just so. Sort of like building a watch, with all the little gears and springs and jewels. There's a beauty in that that goes beyond mere utility.
posted by orthogonality at 8:41 AM on September 1, 2006
Damn, you just moved up several places in "Who's Who in Nerddom".
posted by mr_crash_davis at 8:44 AM on September 1, 2006
posted by mr_crash_davis at 8:44 AM on September 1, 2006
orthogonality: You can be really condescending when it comes to computer stuff some times, you know that? I'd rather matt focus on things like adding new sub-sites and features then fixing timezones. Just because you can figure out how to do something doesn't mean it's worth doing when there are other things on the plate.
posted by delmoi at 8:56 AM on September 1, 2006
posted by delmoi at 8:56 AM on September 1, 2006
If you do fix this, I recommend breaking it completely for a couple of weeks first. Like have all the times be wrong, for everyone.
Then when you fix it, someone will actually notice.
posted by smackfu at 9:05 AM on September 1, 2006
Then when you fix it, someone will actually notice.
posted by smackfu at 9:05 AM on September 1, 2006
orthogonality, I'm not going to do add a database query for every logged in user just to grab their currently correct time that I can feed to other queries. It's a waste of resources for such little gain. Not to mention the ginormous drop-down that a timezone prefs setting would require to list every possible permutation.
What we have now works for most and I can live with that.
posted by mathowie (staff) at 9:06 AM on September 1, 2006
What we have now works for most and I can live with that.
posted by mathowie (staff) at 9:06 AM on September 1, 2006
I deal with people worldwide and amazingly can determine in my head the time difference. I can't even count to 10 without the use of my fingers and I can do it. Both my Windows and Mac systems show the current time on the desktop. When I was in Germany last month, I didn't change my setting in Metafilter for CEST. I did set my watch for the local time. I was not confused that the posts on Metafilter were appearing several hours in the past.
I think Matt should just strip out the time zone stuff here now and just have the posting time in PDT/PST, or to be more international go with GMT. Or he could on the top of the page be like the BBC World Service: It is 1600GMT, 1700 in London, 0900 in Los Angeles and midnight Saturday in Toyko. We're not launching rockets here.
posted by birdherder at 9:09 AM on September 1, 2006
I think Matt should just strip out the time zone stuff here now and just have the posting time in PDT/PST, or to be more international go with GMT. Or he could on the top of the page be like the BBC World Service: It is 1600GMT, 1700 in London, 0900 in Los Angeles and midnight Saturday in Toyko. We're not launching rockets here.
posted by birdherder at 9:09 AM on September 1, 2006
I wonder if it could be fixed in Javascript though. Just create a span with a certain class, then iterate through the DOM and adjust the time as needed.
posted by delmoi at 9:34 AM on September 1, 2006
posted by delmoi at 9:34 AM on September 1, 2006
Personally, I think Matt should introduce MetaTime, one global clock upon which would run all of MetaFilter!
"5 o'clock somewhere"? Au contraire, Pierre!
If it's 14.23 Haughey MeTime in Ho Chi Min City, it's 14.23 in Calgary!
Get on board, this global chronological train leaves the station at 16.00 HMeT on the dot!
Our next stop?
THE FUTURE!!!
posted by Alvy Ampersand at 9:44 AM on September 1, 2006
"5 o'clock somewhere"? Au contraire, Pierre!
If it's 14.23 Haughey MeTime in Ho Chi Min City, it's 14.23 in Calgary!
Get on board, this global chronological train leaves the station at 16.00 HMeT on the dot!
Our next stop?
THE FUTURE!!!
posted by Alvy Ampersand at 9:44 AM on September 1, 2006
That would certainly facilitate world-wide coordination of site-related activities.
Er. There is no cabal.
posted by cortex at 10:01 AM on September 1, 2006
Er. There is no cabal.
posted by cortex at 10:01 AM on September 1, 2006
birdherder writes "I think Matt should just strip out the time zone stuff here now and just have the posting time in PDT/PST, or to be more international go with GMT. "
I'd vote for that if it was GMT. It would also kill confusion where Person A talks about yesterdays PST front page and Person B thinks they are referring to Nuku'alofa's Standard time front page.
posted by Mitheral at 10:14 AM on September 1, 2006
I'd vote for that if it was GMT. It would also kill confusion where Person A talks about yesterdays PST front page and Person B thinks they are referring to Nuku'alofa's Standard time front page.
posted by Mitheral at 10:14 AM on September 1, 2006
MFT: Metafilter Time. Everybody synchronize your watches in 3.....2.....1
posted by grateful at 10:34 AM on September 1, 2006
posted by grateful at 10:34 AM on September 1, 2006
When I was in Germany last month, I didn't change my setting in Metafilter for CEST. I did set my watch for the local time. I was not confused that the posts on Metafilter were appearing several hours in the past.
YES.
PS. Lay off the condescending bullshit, orthogonality. It's not going to make your correct time zone itch go away. It doesn't help other user's impressions of you and it doesn't help your cause.
posted by fake at 10:35 AM on September 1, 2006
YES.
PS. Lay off the condescending bullshit, orthogonality. It's not going to make your correct time zone itch go away. It doesn't help other user's impressions of you and it doesn't help your cause.
posted by fake at 10:35 AM on September 1, 2006
Remember this moment, people: 80 past 2 on April 47th.
posted by Plutor at 11:10 AM on September 1, 2006
posted by Plutor at 11:10 AM on September 1, 2006
I suggest removing the time stamps altogether, and then ordering the comments in stories randomly until people stop complaining about time zones.
posted by boo_radley at 11:24 AM on September 1, 2006
posted by boo_radley at 11:24 AM on September 1, 2006
I like the system as-is. I get to pretend I'm in Japan for half the year. Matt did the best fix a while ago, aligning all 3 sites on time. I just go in and adjust the prefs whenever my sun is taken away or vice versa.
errrr...on preview, I see the times in here are now a bit twisted. Matt! Stop that!
posted by peacay at 11:38 AM on September 1, 2006
errrr...on preview, I see the times in here are now a bit twisted. Matt! Stop that!
posted by peacay at 11:38 AM on September 1, 2006
"It was a bright cold day in April, and the clocks were striking thirteen..."
posted by languagehat at 11:51 AM on September 1, 2006
posted by languagehat at 11:51 AM on September 1, 2006
Maybe Matt can have a user preference to offset the time shown by 10 minutes [or user defined value]. You know, for those strange people that set their clocks 10 minutes fast because they are always running late for something.
[shout]
AND IF YOU DO FIX THE TIME ZONE I JUST NOTICED THE LIVE PREVIEW IS IN PST! SO IS IT 11:53 or 1:53??
[/shout]
posted by birdherder at 11:53 AM on September 1, 2006
[shout]
AND IF YOU DO FIX THE TIME ZONE I JUST NOTICED THE LIVE PREVIEW IS IN PST! SO IS IT 11:53 or 1:53??
[/shout]
posted by birdherder at 11:53 AM on September 1, 2006
and here I thought MetaFilter posts were timeless...
posted by owhydididoit at 11:56 AM on September 1, 2006
posted by owhydididoit at 11:56 AM on September 1, 2006
"Twelve!" said the bell.
"Dvelf!" they replied perfectly satisfied, and dropping their voices.
"Und dvelf it is!" said all the little old gentlemen, putting up their watches. But the big bell had not done with them yet.
"Thirteen!" said he.
"Der Teufel!" gasped the little old gentlemen, turning pale, dropping their pipes, and putting down all their right legs from over their left knees.
"Der Teufel!" groaned they, "Dirteen! Dirteen!! -- Mein Gott, it is Dirteen o'clock!!"
Why attempt to describe the terrible scene which ensued? All Vondervotteimittiss flew at once into a lamentable state of uproar.
-EAP
posted by yeti at 12:15 PM on September 1, 2006
"Dvelf!" they replied perfectly satisfied, and dropping their voices.
"Und dvelf it is!" said all the little old gentlemen, putting up their watches. But the big bell had not done with them yet.
"Thirteen!" said he.
"Der Teufel!" gasped the little old gentlemen, turning pale, dropping their pipes, and putting down all their right legs from over their left knees.
"Der Teufel!" groaned they, "Dirteen! Dirteen!! -- Mein Gott, it is Dirteen o'clock!!"
Why attempt to describe the terrible scene which ensued? All Vondervotteimittiss flew at once into a lamentable state of uproar.
-EAP
posted by yeti at 12:15 PM on September 1, 2006
mathowie writes "orthogonality, I'm not going to do add a database query for every logged in user just to grab their currently correct time that I can feed to other queries. It's a waste of resources for such little gain."
Matt, you already do this.
To display the adjusted time to any logged in user, you have to query the database when the user logs in, to find the user's timezone preference (which you then save as a cookie on the user's machine). Presumably, when you display a thread, you have to add the offset for that timezone to each comment's timestamp, and display the correct timezone string ( "PDT") following the time. In all likelihood, it'd actually be more efficient and faster to do the time offset addition, and concatenating of the timezone string, in the database than in the Cold Fusion code. You'd save server resources.
(At the risk of sounding condescending: either you also already do the addition and concatenation in the database, in which case it's no more costly, or you do it in Cold Fusion, which requires the database connectivity layer to convert the internal (probably integer) database time representation to a database Timestamp (a database transport layer C API level memory allocation and memcpy, at minimum, at each end of the transport layer) which JDBC then converts to a Java sql.Date-type (another memory allocation and probable addition). Cold Fusion then has to call a Java Date function to add the timezone offset (an integer addition in Java), then convert the Date-type to a Java String (a memory allocation and a series of divisions and remainders) to get the displayed date String. And that's a best-case, assuming no intervening conversion in the database transport layer to a string representation (depends on your version of JDBC drivers). Doing it all in the database would allow you to just pull a String-type out of the database. you'd save at minimum one conversion and one memory allocation, and probably more, and in all likelihood the C code in the database runs faster than even the native-C-functions in the Java Virtual Machine.)
posted by orthogonality at 1:13 PM on September 1, 2006
Matt, you already do this.
To display the adjusted time to any logged in user, you have to query the database when the user logs in, to find the user's timezone preference (which you then save as a cookie on the user's machine). Presumably, when you display a thread, you have to add the offset for that timezone to each comment's timestamp, and display the correct timezone string ( "PDT") following the time. In all likelihood, it'd actually be more efficient and faster to do the time offset addition, and concatenating of the timezone string, in the database than in the Cold Fusion code. You'd save server resources.
(At the risk of sounding condescending: either you also already do the addition and concatenation in the database, in which case it's no more costly, or you do it in Cold Fusion, which requires the database connectivity layer to convert the internal (probably integer) database time representation to a database Timestamp (a database transport layer C API level memory allocation and memcpy, at minimum, at each end of the transport layer) which JDBC then converts to a Java sql.Date-type (another memory allocation and probable addition). Cold Fusion then has to call a Java Date function to add the timezone offset (an integer addition in Java), then convert the Date-type to a Java String (a memory allocation and a series of divisions and remainders) to get the displayed date String. And that's a best-case, assuming no intervening conversion in the database transport layer to a string representation (depends on your version of JDBC drivers). Doing it all in the database would allow you to just pull a String-type out of the database. you'd save at minimum one conversion and one memory allocation, and probably more, and in all likelihood the C code in the database runs faster than even the native-C-functions in the Java Virtual Machine.)
posted by orthogonality at 1:13 PM on September 1, 2006
To display the adjusted time to any logged in user, you have to query the database when the user logs in, to find the user's timezone preference (which you then save as a cookie on the user's machine)
Actually it's much simpler. The cookie is just number of hours from the PST offset. I just check your cookie value if it exists (say it's -3) then offset date displays by that number.
I only offer 25 or so timezone options on the prefs page, and they're actually written out in HTML, not even in a db. So going to a db-backed solution with 300+ zones and all the rules and exceptions for when and where times change for DST would be much more complicated.
Not to mention that after your time zone changes for DST, your cookie won't be updated and you'd have to reset it again to be correct, then reset it again when the server's US-based DST kicks in.
See how this is a clusterfuck not worth the effort to get perfectly correct?
posted by mathowie (staff) at 1:52 PM on September 1, 2006
Actually it's much simpler. The cookie is just number of hours from the PST offset. I just check your cookie value if it exists (say it's -3) then offset date displays by that number.
I only offer 25 or so timezone options on the prefs page, and they're actually written out in HTML, not even in a db. So going to a db-backed solution with 300+ zones and all the rules and exceptions for when and where times change for DST would be much more complicated.
Not to mention that after your time zone changes for DST, your cookie won't be updated and you'd have to reset it again to be correct, then reset it again when the server's US-based DST kicks in.
See how this is a clusterfuck not worth the effort to get perfectly correct?
posted by mathowie (staff) at 1:52 PM on September 1, 2006
Oo... oo... I have an idea!!! (Okay, two, actually.)
Instead of Having, say UTC-3.5 (Newfoundland) in the dropdown, just allow people to calculate and enter there own offsets and drop the timecode altogether. If I have a pressing need to see posts dated 3 weeks 2 days and 9.235 hours in the future, I have to do it myself.
Or just make everyone see GMT and drop the option altogether.
Either way, no more whining allowed.
posted by timeistight at 2:22 PM on September 1, 2006
Instead of Having, say UTC-3.5 (Newfoundland) in the dropdown, just allow people to calculate and enter there own offsets and drop the timecode altogether. If I have a pressing need to see posts dated 3 weeks 2 days and 9.235 hours in the future, I have to do it myself.
Or just make everyone see GMT and drop the option altogether.
Either way, no more whining allowed.
posted by timeistight at 2:22 PM on September 1, 2006
Instead of Having, say UTC-3.5 (Newfoundland) in the dropdown
BURN THE HERETIC!
</expat Newfoundlander>
posted by hangashore at 2:38 PM on September 1, 2006
BURN THE HERETIC!
</expat Newfoundlander>
posted by hangashore at 2:38 PM on September 1, 2006
Not to mention that after your time zone changes for DST
... you realize you should move to Saskatchewan where we stubbornly don't change to DST with the rest of North America?
No?
posted by raedyn at 2:41 PM on September 1, 2006
... you realize you should move to Saskatchewan where we stubbornly don't change to DST with the rest of North America?
No?
posted by raedyn at 2:41 PM on September 1, 2006
... you realize you should move to Saskatchewan where we stubbornly don't change to DST with the rest of North America?
Not so much stubborn as kind to your neighbours, i.e. you let Alberta catch up to you and Manitoba go ahead for half the year. Saskatchepudlians - always putting others first.
Oh, and Arizona and Hawaii don't do DST either. To clear the confusion, may I suggest the Federation of Saskatchazonawaii?
posted by hangashore at 2:53 PM on September 1, 2006
Not so much stubborn as kind to your neighbours, i.e. you let Alberta catch up to you and Manitoba go ahead for half the year. Saskatchepudlians - always putting others first.
Oh, and Arizona and Hawaii don't do DST either. To clear the confusion, may I suggest the Federation of Saskatchazonawaii?
posted by hangashore at 2:53 PM on September 1, 2006
You know who else didn't code a database-driven timezone feature on a community weblog?
posted by Saucy Intruder at 3:30 PM on September 1, 2006
posted by Saucy Intruder at 3:30 PM on September 1, 2006
I don't see how the fixes you propose cover every little state rule within India and Indiana (within the single state there is one timezone doing DST, then another that doesn't want DST).
The entire state of Indiana has been on DST since April 2. Of course, they put us in the wrong geographic time zone (EST rather than CST), but that's another issue.
posted by KirkJobSluder at 3:30 PM on September 1, 2006
The entire state of Indiana has been on DST since April 2. Of course, they put us in the wrong geographic time zone (EST rather than CST), but that's another issue.
posted by KirkJobSluder at 3:30 PM on September 1, 2006
saskatchazonawaiipartsofindiana
If you say it loud enough you'll always sound bananas...
posted by hangashore at 3:36 PM on September 1, 2006
If you say it loud enough you'll always sound bananas...
posted by hangashore at 3:36 PM on September 1, 2006
Frankly, I'm surprised MetaFilter doesn't run on Internet Time. That would solve the pesky timezone problem completely.
posted by EndsOfInvention at 3:44 PM on September 1, 2006
posted by EndsOfInvention at 3:44 PM on September 1, 2006
You know who else didn't code a database-driven timezone feature on a community weblog?
Hitler!
posted by Johnny Assay at 4:11 PM on September 1, 2006
Hitler!
posted by Johnny Assay at 4:11 PM on September 1, 2006
So, anyway, I re-commanded my profile's preference and the time zone cookie got set (had to let it in) and now everything's hunky dory.
Exceptin' for the EST/EDT/Eastern thing, of course. Glad to see that there's lots of interest in me stirring this up twice a year :)
posted by intermod at 8:03 PM on September 1, 2006
Exceptin' for the EST/EDT/Eastern thing, of course. Glad to see that there's lots of interest in me stirring this up twice a year :)
posted by intermod at 8:03 PM on September 1, 2006
Matt what you need to do is use PostgreSQL's GIS software to convert users' coordinates into time zones and use that to figure out the proper time.
posted by delmoi at 2:09 AM on September 2, 2006
posted by delmoi at 2:09 AM on September 2, 2006
This is just stupid. A lookup table for a user's timezone? Even offering a "timezone" dropdown? Crazy-talk.
It's simple. Everyone is running at whatever time they think is correct, right? So if everyone's browser were to execute a new Date(), they'd get the current date for whereever they are. And there's the trick: MeFi has it's own internal clock that says what time it thinks is correct.
So.
Subtract the MeFi current time from the user's current time, and you get their offset. Subtract that offset from any date in the database and you have the date relative to the user. Easy.
Since the method is determined at runtime on the client's side (wherever the client is located, that's their version of the "correct" base time), dates could be dynamically altered on the client's side. Wrap each date in a <span class="dateShift"> and perform the necessary time transformations on the client's side in javascript.
The downside is that people without Javascript would be ignored. So is life. Maybe you could keep the user-pref drop-down for those outliers (80-20 as you say...). The upshot is that the server has to perform only a single operation: getDate(). That actually uses less cycles than looking up everyone's preferences and recalculating the display date. It shifts the processing to the client, which reduces server load. And it gives users a date that's accurate, no matter where they are in the world, without needing to set a preference.
posted by Civil_Disobedient at 5:41 AM on September 2, 2006
It's simple. Everyone is running at whatever time they think is correct, right? So if everyone's browser were to execute a new Date(), they'd get the current date for whereever they are. And there's the trick: MeFi has it's own internal clock that says what time it thinks is correct.
So.
Subtract the MeFi current time from the user's current time, and you get their offset. Subtract that offset from any date in the database and you have the date relative to the user. Easy.
Since the method is determined at runtime on the client's side (wherever the client is located, that's their version of the "correct" base time), dates could be dynamically altered on the client's side. Wrap each date in a <span class="dateShift"> and perform the necessary time transformations on the client's side in javascript.
The downside is that people without Javascript would be ignored. So is life. Maybe you could keep the user-pref drop-down for those outliers (80-20 as you say...). The upshot is that the server has to perform only a single operation: getDate(). That actually uses less cycles than looking up everyone's preferences and recalculating the display date. It shifts the processing to the client, which reduces server load. And it gives users a date that's accurate, no matter where they are in the world, without needing to set a preference.
posted by Civil_Disobedient at 5:41 AM on September 2, 2006
It's hard damned work being this clever.
posted by Civil_Disobedient at 5:43 AM on September 2, 2006
posted by Civil_Disobedient at 5:43 AM on September 2, 2006
I'm in Agra, India (GMT+5.5). I have my local clock set to Tokyo (GMT+9). I ssh to a colocated machine in Fernando de Noronha (GMT-2) that has its time zone set to Addis Ababa (GMT+3) and export an X session and run Firefox through it. MeFi is configured to show me Juneau, Alaska time (GMT-9).
Your solution hurts me, CD.
posted by Plutor at 7:07 AM on September 2, 2006 [1 favorite]
Your solution hurts me, CD.
posted by Plutor at 7:07 AM on September 2, 2006 [1 favorite]
CD, it's fewer cycles actually....
posted by jessamyn (staff) at 7:31 AM on September 2, 2006 [1 favorite]
fewer
My expertise is in cleverness and all aspects of neatnissitude, not languagistics.
I'll have a working example up after I have some more coffee.
posted by Civil_Disobedient at 10:43 AM on September 2, 2006
My expertise is in cleverness and all aspects of neatnissitude, not languagistics.
I'll have a working example up after I have some more coffee.
posted by Civil_Disobedient at 10:43 AM on September 2, 2006
dates could be dynamically altered on the client's side
Or, the local time could be sniffed when starting a session (logging in and/or returning to the site), and compared to the server time and used to adjust the times server-side for that session...
posted by kindall at 11:01 AM on September 2, 2006
Or, the local time could be sniffed when starting a session (logging in and/or returning to the site), and compared to the server time and used to adjust the times server-side for that session...
posted by kindall at 11:01 AM on September 2, 2006
OK, here's a quick mock-up.
The "server date" is the actual posted timestamp relative to the server. In practice, you wouldn't see this value at all. I'm EST, so you folks on the East Coast of the U.S. should see very-nearly the same date/time. Also note that this is to-the-second accurate. In other words, if your clocks are set ten minutes fast on the east coast, the time reflected will be ten minutes faster than the server's recorded time.
I think I drank too much coffee, because all this thinking about relative time is giving me a headache.
posted by Civil_Disobedient at 12:53 PM on September 2, 2006
The "server date" is the actual posted timestamp relative to the server. In practice, you wouldn't see this value at all. I'm EST, so you folks on the East Coast of the U.S. should see very-nearly the same date/time. Also note that this is to-the-second accurate. In other words, if your clocks are set ten minutes fast on the east coast, the time reflected will be ten minutes faster than the server's recorded time.
I think I drank too much coffee, because all this thinking about relative time is giving me a headache.
posted by Civil_Disobedient at 12:53 PM on September 2, 2006
It's hard damned work being this clever. - Civil_Disobedient
*waves palm frond, blots sweat from C_D's brow*
posted by raedyn at 4:43 PM on September 2, 2006
*waves palm frond, blots sweat from C_D's brow*
posted by raedyn at 4:43 PM on September 2, 2006
orthogonality writes "I wrote a Greasemonkey script that fixes the incorrect timezones"
Civil_Disobedient writes "Subtract the MeFi current time from the user's current time, and you get their offset. Subtract that offset from any date in the database and you have the date relative to the user. Easy."
Yeah, that's basically what my script does, though it's a bit more compilcated.
posted by orthogonality at 5:57 PM on September 2, 2006
Civil_Disobedient writes "Subtract the MeFi current time from the user's current time, and you get their offset. Subtract that offset from any date in the database and you have the date relative to the user. Easy."
Yeah, that's basically what my script does, though it's a bit more compilcated.
posted by orthogonality at 5:57 PM on September 2, 2006
Yeah, that's basically what my script does, though it's a bit more compilcated.
I don't quite understand how your GM script is supposed to work. Are you just best-guessing the server's time? Or are you grabbing it from the masthead and manipulating the heck out of the string?
posted by Civil_Disobedient at 6:13 PM on September 2, 2006
I don't quite understand how your GM script is supposed to work. Are you just best-guessing the server's time? Or are you grabbing it from the masthead and manipulating the heck out of the string?
posted by Civil_Disobedient at 6:13 PM on September 2, 2006
Even with a nifty database-driven solution, someone's got to maintain the database.
I way prefer that that someone do something else with his time.
posted by bigbigdog at 8:46 PM on September 2, 2006
I way prefer that that someone do something else with his time.
posted by bigbigdog at 8:46 PM on September 2, 2006
bbg: If you read my suggestion, there is no need to even touch the database. Here, bullet points for the slow:
posted by Civil_Disobedient at 4:45 AM on September 3, 2006
- No change to existing database structure
- No need to perform time adjustments based on DB lookups
- Lower overhead for the server ( == faster server)
- The most accurate representation of post-time possible for the user (adjusted down to the second)
- ...and the user doesn't have to even pick their timezone from a drop-down ( == less work for the user)
- Time changes follow the user, so no reconfiguration required
posted by Civil_Disobedient at 4:45 AM on September 3, 2006
OK, posting right after I just posted, but here's an illustration of what I mean when I say "accurate to the second". I'm looking at that post time above and it's two minutes before my clock. No biggy, sure. But that means the server clock (or my clock) is two minutes off. By comparing the system time with the user time, the post time would be accurate to the second.
Also, I know this isn't rocket science and no one really needs to-the-second accuracy, but it's a nice by-product of the method.
posted by Civil_Disobedient at 4:49 AM on September 3, 2006
Also, I know this isn't rocket science and no one really needs to-the-second accuracy, but it's a nice by-product of the method.
posted by Civil_Disobedient at 4:49 AM on September 3, 2006
Or to put another spin on it as a person who has been a life-long resident of a non-DST region currently in recovery:
It's not a big fucking deal. At least in the US, the fact that most television stations and services either showed EST or CST was just one of those things that we learned to live with. You do the mental arithmatic in your head, and get on with it.
posted by KirkJobSluder at 5:18 AM on September 3, 2006
It's not a big fucking deal. At least in the US, the fact that most television stations and services either showed EST or CST was just one of those things that we learned to live with. You do the mental arithmatic in your head, and get on with it.
posted by KirkJobSluder at 5:18 AM on September 3, 2006
And it's metafilter. I know that we specialize here in overwrought debates over trivial shit, but this is trivial shit here.
posted by KirkJobSluder at 5:29 AM on September 3, 2006
posted by KirkJobSluder at 5:29 AM on September 3, 2006
Civil_Disobedient writes "Or are you grabbing it from the masthead and manipulating the heck out of the string?"
Yes, this is necessary because the timestamps displayed on comments don't show the year; a good solution requires both parsing the thread date (technically, it's not a "masthead") and applying certain heuristics, which my script does. (Among other difficulties: if the server time is "11:01 PM PST on February 28", what is that in CST?)
Civil_Disobedient writes "The most accurate representation of post-time possible for the user (adjusted down to the second)"
This is a non-issue. If a comment's timestamp is "4:45 AM PDT" it (putatively) was posted at exactly 4:45 AM PDT == exactly 11:45 AM UTC server time. Matt throws away seconds (at least on display, I have no idea what he keeps in his database), so no matter what the reader's clock is set to, the comment happened at 4:45:00.000 AM PDT == exactly 11:45:00.000 AM UTC (on some date).
You're not looking at the reader's clock to find out what time it is (the reader might be reading it a year and two months hence), but to determine the reader's timezone offset.
And this still doesn't really work, because for most daylight savings time, the actual calendar days DST is in effect changes each year. Knowing the reader's timezone is in DST (or not) now doesn't tell you if the he was in DST when the comment was made.
So you have to actually take each displayed date, correct to UTC, create a UTC date for that time, then apply the reader's timezone (which does correct, correctly, for DST) then display that date rather than the server date. In theory, the javascript (which is ironically, at least in Firefox is implemented in Java) has some subset of "all" the timezone rules, so it ought to know that in the US, April 6 1987 is in DST and April 6 1977 is not DST and January (!) 6 1974 after 2am is in DST. (In fact, it doesn't: javascript in FF incorrectly applies the US 1987-2006 rule to all dates.)
The simpler hack, seeing if the server shows "PST" or "DST", happens to work for US readers, because then the server's rule for when DST begins is also the reader's rule. This hack fails if the reader's DST rule isn't the US rule; another rule may start or end DST on different days than US DST.
Civil_Disobedient writes "I suppose I could get all Pangloss here and talk about how this is the best of all possible worlds,"
IIF (if and only if) the user has and allows javascript (I do, and usually don't allow it, on my desktop; on my handheld I don't have it). Javascript (Web 2.0!11!11!) solutions I don't particularly like for exactly that reason. (FF Extensions are a special case, because the user, not the site, controls them.)
posted by orthogonality at 5:49 AM on September 3, 2006
Yes, this is necessary because the timestamps displayed on comments don't show the year; a good solution requires both parsing the thread date (technically, it's not a "masthead") and applying certain heuristics, which my script does. (Among other difficulties: if the server time is "11:01 PM PST on February 28", what is that in CST?)
Civil_Disobedient writes "The most accurate representation of post-time possible for the user (adjusted down to the second)"
This is a non-issue. If a comment's timestamp is "4:45 AM PDT" it (putatively) was posted at exactly 4:45 AM PDT == exactly 11:45 AM UTC server time. Matt throws away seconds (at least on display, I have no idea what he keeps in his database), so no matter what the reader's clock is set to, the comment happened at 4:45:00.000 AM PDT == exactly 11:45:00.000 AM UTC (on some date).
You're not looking at the reader's clock to find out what time it is (the reader might be reading it a year and two months hence), but to determine the reader's timezone offset.
And this still doesn't really work, because for most daylight savings time, the actual calendar days DST is in effect changes each year. Knowing the reader's timezone is in DST (or not) now doesn't tell you if the he was in DST when the comment was made.
So you have to actually take each displayed date, correct to UTC, create a UTC date for that time, then apply the reader's timezone (which does correct, correctly, for DST) then display that date rather than the server date. In theory, the javascript (which is ironically, at least in Firefox is implemented in Java) has some subset of "all" the timezone rules, so it ought to know that in the US, April 6 1987 is in DST and April 6 1977 is not DST and January (!) 6 1974 after 2am is in DST. (In fact, it doesn't: javascript in FF incorrectly applies the US 1987-2006 rule to all dates.)
The simpler hack, seeing if the server shows "PST" or "DST", happens to work for US readers, because then the server's rule for when DST begins is also the reader's rule. This hack fails if the reader's DST rule isn't the US rule; another rule may start or end DST on different days than US DST.
Civil_Disobedient writes "I suppose I could get all Pangloss here and talk about how this is the best of all possible worlds,"
IIF (if and only if) the user has and allows javascript (I do, and usually don't allow it, on my desktop; on my handheld I don't have it). Javascript (Web 2.0!11!11!) solutions I don't particularly like for exactly that reason. (FF Extensions are a special case, because the user, not the site, controls them.)
posted by orthogonality at 5:49 AM on September 3, 2006
You're not looking at the reader's clock to find out what time it is (the reader might be reading it a year and two months hence), but to determine the reader's timezone offset.
Um, Ortho, that's exactly what I'm doing. :)
I think we are talking about the exact same method, except I have the benefit of controlling the server, and thus can get around a whole load of string parsing that you have to do because you don't.
To wit:
Date is stored in database. That date is absolute. Reader comes to Mefi, some number of seconds, minutes, days, months or years later, and looks at a timestamp. The server says, "This is the time I recorded, and this is the time I currently think it is." All these dates are UTC, obviously! The datetime the server thinks is "current" is injected into a javascript method that subtracts the what the user's browser says is the current time. That's your offset. Once you have the offset, you're gold. Take a look at my page source and you'll see what I mean.
The cs_Offset variable takes a UTC date (injected from the server) and subtracts the client's current UTC date. The dates inside the
posted by Civil_Disobedient at 6:24 AM on September 3, 2006
Um, Ortho, that's exactly what I'm doing. :)
I think we are talking about the exact same method, except I have the benefit of controlling the server, and thus can get around a whole load of string parsing that you have to do because you don't.
To wit:
Date is stored in database. That date is absolute. Reader comes to Mefi, some number of seconds, minutes, days, months or years later, and looks at a timestamp. The server says, "This is the time I recorded, and this is the time I currently think it is." All these dates are UTC, obviously! The datetime the server thinks is "current" is injected into a javascript method that subtracts the what the user's browser says is the current time. That's your offset. Once you have the offset, you're gold. Take a look at my page source and you'll see what I mean.
The cs_Offset variable takes a UTC date (injected from the server) and subtracts the client's current UTC date. The dates inside the
SPANs are all UTC dates as well, using the query column: DATEDIFF(second, '19700101', date), where date is the column that holds the timestamp when the article was posted.posted by Civil_Disobedient at 6:24 AM on September 3, 2006
Civil_Disobedient writes "The datetime the server thinks is 'current' is injected into a javascript method that subtracts the what the user's browser says is the current time. That's your offset. "
Ok, let's say I live in London. That means my Standard Time is UTC/GMT, and my DST is British Summer Time, which is GMT + 1.
Now let's say I'm looking at a comment posted in January (which is prior to BST). The comment was posted January 1 at, say 2 PM UTC. If I look at it in January, you see my time is the server's time is UTC time and so my offset is 0, and you tell me the comment was posted at 1 PM.
Now in April, I look at the same comment. I'm now in British Summer Time, and so the difference between the server's UTC time and my BST time is one hour. So do you now tell me the same comment was posted at 3PM?
Do you get even weirder on me, and tell me that the comment's date is 3PM January 1st BST? Because that's an illegal date: No January date is ever BST, because BST doesn't start until sometime (depending on the year) in March (and ends sometime in October).
posted by orthogonality at 8:18 AM on September 3, 2006
Ok, let's say I live in London. That means my Standard Time is UTC/GMT, and my DST is British Summer Time, which is GMT + 1.
Now let's say I'm looking at a comment posted in January (which is prior to BST). The comment was posted January 1 at, say 2 PM UTC. If I look at it in January, you see my time is the server's time is UTC time and so my offset is 0, and you tell me the comment was posted at 1 PM.
Now in April, I look at the same comment. I'm now in British Summer Time, and so the difference between the server's UTC time and my BST time is one hour. So do you now tell me the same comment was posted at 3PM?
Do you get even weirder on me, and tell me that the comment's date is 3PM January 1st BST? Because that's an illegal date: No January date is ever BST, because BST doesn't start until sometime (depending on the year) in March (and ends sometime in October).
posted by orthogonality at 8:18 AM on September 3, 2006
orthogonality writes "and you tell me the comment was posted at 1 PM."
Sorry, you tell me 2 PM.
posted by orthogonality at 8:19 AM on September 3, 2006
Sorry, you tell me 2 PM.
posted by orthogonality at 8:19 AM on September 3, 2006
I don't think I made it clear that I'm taking the user's locale into effect twice -- the first time is when the JS method asks for what the client thinks the current UTC time is. The second time is when I correct for the offset. The method I use is:
Do you get even weirder on me
That's a loaded question. :)
posted by Civil_Disobedient at 11:20 AM on September 3, 2006
cs_Offset = [injected server current date_UTC] - parseInt(new Date().getTime()/1000, 10);
localOffset = d.getTimezoneOffset() * 60000;
newUTC = post_UTC_timestamp - cs_Offset;
d = new Date(newUTC*1000 + localOffset);
newDateString = d.toLocaleString();Do you get even weirder on me
That's a loaded question. :)
posted by Civil_Disobedient at 11:20 AM on September 3, 2006
Also:
a good solution requires both parsing the thread date (technically, it's not a "masthead")
That thing up at the top of the screen? The thing that says MetaFilter with a bunch of links and the date smack-dab in the middle of it? That's a masthead.
Anyway, I'm thinking more about what you said and confusing myself thoroughly because of it.
posted by Civil_Disobedient at 12:00 PM on September 3, 2006
a good solution requires both parsing the thread date (technically, it's not a "masthead")
That thing up at the top of the screen? The thing that says MetaFilter with a bunch of links and the date smack-dab in the middle of it? That's a masthead.
Anyway, I'm thinking more about what you said and confusing myself thoroughly because of it.
posted by Civil_Disobedient at 12:00 PM on September 3, 2006
Awe crap, I could have made this so much easier.
OK, new method that actually (probably) works.
Use a good query to generate the actual UTC!
There, now it should work fine. All the browser does it take the UTC value and turn it into a local time based on the locale. Just a simple:
posted by Civil_Disobedient at 12:27 PM on September 3, 2006
OK, new method that actually (probably) works.
Use a good query to generate the actual UTC!
SELECT DATEDIFF(second, '19700101', DATEADD(second, DATEDIFF(second, GETDATE(), GETUTCDATE()), date)) as utc ...There, now it should work fine. All the browser does it take the UTC value and turn it into a local time based on the locale. Just a simple:
new Date(utcdate).toLocaleString().
I'm always making things more difficult for myself.posted by Civil_Disobedient at 12:27 PM on September 3, 2006
I can't believe you people are fighting over time zones.
posted by dersins at 1:42 PM on September 3, 2006
posted by dersins at 1:42 PM on September 3, 2006
I'm thrilled, personally. This is the kind of geekery I live for.
posted by cortex at 1:45 PM on September 3, 2006
posted by cortex at 1:45 PM on September 3, 2006
I respect Orthogonality and hold his intellect in high regard, so I wouldn't be so insulting as to fight with him when he's just pointing out flaws in my reasoning. It's when reason turns to dogma that fervent discussions turn into nasty fighting.
posted by Civil_Disobedient at 2:22 PM on September 3, 2006
posted by Civil_Disobedient at 2:22 PM on September 3, 2006
Eh, nobody's fighting. We're just having a good thorough discussion on a couple of different levels: a goal/need level of whether time zone accuracy is worth the cost of having it, what that cost really is, and then C_D and me over correct implementation.
C_D's making an interesting move: he sees, he thinks, a way way to cut the Gordian knot. This is a time-honorted hacker's move (I use hacker in the best sense). I, as I usually do in these discussions, am holding out for a certain formalism (mostly because I read comp.lang.c++.moderated, and long to shout "undefined behavior!" whilst citing a paragraph of the One True and Holy Standard).
So now I'm betting C_D hasn't considered the corner cases (which is always a safe bet; considering all corner cases is what makes programming hard, and because I've written the GM script and most of the database solution I refrenced above, I have made acquantance of many of these corner cases), and I'm throwing corner case examples at him to see how he disposes of them.
It's not a fight, it's not even playing the dozens. It's more like a pick-up game of one-on-one or a game of handball, a chance to work up a sweat and and work off a few calories.
posted by orthogonality at 3:16 PM on September 3, 2006
C_D's making an interesting move: he sees, he thinks, a way way to cut the Gordian knot. This is a time-honorted hacker's move (I use hacker in the best sense). I, as I usually do in these discussions, am holding out for a certain formalism (mostly because I read comp.lang.c++.moderated, and long to shout "undefined behavior!" whilst citing a paragraph of the One True and Holy Standard).
So now I'm betting C_D hasn't considered the corner cases (which is always a safe bet; considering all corner cases is what makes programming hard, and because I've written the GM script and most of the database solution I refrenced above, I have made acquantance of many of these corner cases), and I'm throwing corner case examples at him to see how he disposes of them.
It's not a fight, it's not even playing the dozens. It's more like a pick-up game of one-on-one or a game of handball, a chance to work up a sweat and and work off a few calories.
posted by orthogonality at 3:16 PM on September 3, 2006
Well said, ortho.
So what do you think of the above? In practice, it'd be best to define the offset as a variable so you're not computing it over and over again--though the database might cache these things... I dunno. Something like:
That's about as efficient a way as I can think of to convert every single date in the DB to it's proper UTC date, and that's assuming Matt doesn't already save the dates in UTC (though I doubt it). But this does add a very slight amount of overhead to the query, which I had hoped to push to the client side.
But I think you'll like the final version. It even degrades nicely for those without Javascript, and as you can see from the code, there are no additional JavaScript functions required. Just a straight inline convert/document.write. It could not be any simpler, and it should work no matter what crazy daylight-saving rules your locale has.
posted by Civil_Disobedient at 4:29 PM on September 3, 2006
So what do you think of the above? In practice, it'd be best to define the offset as a variable so you're not computing it over and over again--though the database might cache these things... I dunno. Something like:
DECLARE @ServerOffset DATETIME
SET @ServerOffset = DATEDIFF(second, GETDATE(), GETUTCDATE())
SELECT DATEDIFF(second, '19700101', DATEADD(second, @ServerOffset, date)) as utcdateThat's about as efficient a way as I can think of to convert every single date in the DB to it's proper UTC date, and that's assuming Matt doesn't already save the dates in UTC (though I doubt it). But this does add a very slight amount of overhead to the query, which I had hoped to push to the client side.
But I think you'll like the final version. It even degrades nicely for those without Javascript, and as you can see from the code, there are no additional JavaScript functions required. Just a straight inline convert/document.write. It could not be any simpler, and it should work no matter what crazy daylight-saving rules your locale has.
posted by Civil_Disobedient at 4:29 PM on September 3, 2006
I can't believe you people are fighting over time zones.
- dersins
I'm guessing you haven't lived anywhere in North America that doesn't do DST. We* fight over time zones in the local paper twice every year, while the rest of the continent switches their clocks.
At least it gives us something to talk about other than the weather.
* (and by "we" I mean not me - I've got other things to worry about - but certainly everyone with too much time on their hands like seniors and newspaper opinion columnists)
posted by raedyn at 7:42 AM on September 5, 2006
- dersins
I'm guessing you haven't lived anywhere in North America that doesn't do DST. We* fight over time zones in the local paper twice every year, while the rest of the continent switches their clocks.
At least it gives us something to talk about other than the weather.
* (and by "we" I mean not me - I've got other things to worry about - but certainly everyone with too much time on their hands like seniors and newspaper opinion columnists)
posted by raedyn at 7:42 AM on September 5, 2006
You are not logged in, either login or create an account to post comments
posted by intermod at 8:36 PM on August 31, 2006