Plenty of good grazing come Spring and Autumn March 24, 2013 7:57 AM Subscribe
...so I'm hoping against hope that there's room in the paddock this year for an old nag to keep all the new ponies company.
Apparently Daylight Saving has just started where the server is, so I've had to adjust my profile time offset backward by an hour. And when Daylight Saving ends where I am, which it will do in early April, I will need to adjust it back by another hour. And I will need to do this whole stupid anachronistic dance over again on every device I use to talk to MeFi, while remembering how all my other preferences are supposed to be set per device.
Is there still no way the server could keep and send UTC timestamps and have the browser convert them automatically, possibly taking an optional profile timezone preference into account?
Apparently Daylight Saving has just started where the server is, so I've had to adjust my profile time offset backward by an hour. And when Daylight Saving ends where I am, which it will do in early April, I will need to adjust it back by another hour. And I will need to do this whole stupid anachronistic dance over again on every device I use to talk to MeFi, while remembering how all my other preferences are supposed to be set per device.
Is there still no way the server could keep and send UTC timestamps and have the browser convert them automatically, possibly taking an optional profile timezone preference into account?
I'm sorry about this inconvenience. We've looked at this, and moving to using UTC on the server is a bigger project than we want to tackle right now. We know the cost of continuing to run in local time is this inconvenience twice/year (sometimes four times/year for people with mismatched DST shifts) and in a perfect world we'd like to fix this. But we have fourteen years of posts and comments in Pacific Time (and the resulting DST shifts) that would need to be converted to UTC—we can't simply shift one day and start using UTC.
Complicating things is the environment we're running in, Cold Fusion 9, which doesn't offer good timezone shifting tools. So between writing our own timezone handling tools and converting historic dates and times it's just something that will take many resources to solve a minor annoyance. In the past I think I've described it as trying to re-build the foundation of a house while you're still living in it. If I could go back to 1999 and make different choices for MetaFilter, I definitely would.
The jQuery library you linked to doesn't really do much for us—it's all about how the dates are stored in the database.
posted by pb (staff) at 8:12 AM on March 24, 2013 [1 favorite]
Complicating things is the environment we're running in, Cold Fusion 9, which doesn't offer good timezone shifting tools. So between writing our own timezone handling tools and converting historic dates and times it's just something that will take many resources to solve a minor annoyance. In the past I think I've described it as trying to re-build the foundation of a house while you're still living in it. If I could go back to 1999 and make different choices for MetaFilter, I definitely would.
The jQuery library you linked to doesn't really do much for us—it's all about how the dates are stored in the database.
posted by pb (staff) at 8:12 AM on March 24, 2013 [1 favorite]
flabdablet, is a there a specific reason you want the timestamps to be accurate?
I do not intend snark or sarcasm with this question. I believe that comments and posts show up correctly and immediately in the right order no matter what (but please correct me if I'm wrong) no matter what the timestamps say. It just doesn't particularly bother me if timestamps don't match my clock.
posted by insectosaurus at 8:21 AM on March 24, 2013 [4 favorites]
I do not intend snark or sarcasm with this question. I believe that comments and posts show up correctly and immediately in the right order no matter what (but please correct me if I'm wrong) no matter what the timestamps say. It just doesn't particularly bother me if timestamps don't match my clock.
posted by insectosaurus at 8:21 AM on March 24, 2013 [4 favorites]
A gresemonkey script could potentially use a timezone library like timezone-js to accurately convert timestamps in the America/Los_Angeles zone to GMT and thence to the user's zone, all on the client's side. The main bit would be accurately finding and parsing the time and date at each location where it can appear and in each possible format; the second bit would be re-running the script after loading more comments.
posted by jepler at 8:34 AM on March 24, 2013
posted by jepler at 8:34 AM on March 24, 2013
OK, so let's assume for the sake of argument that you did just pick a time after which all new timestamps would be stored and served as UTC, and made no attempt at all to do any historical adjustment for timestamps earlier than that. Couldn't that actually be made to work?
Timestamps with post-cutover values would be sent with a suitable tag to make an accompanying jquery snippet treat them as UTC values in need of local munging. Because all such conversions happen client-side, done by browsers that already know their own current offset from UTC, you wouldn't need any server-size time zone processing at all.
Pre-cutover timestamps could be rendered exactly the way you're already doing them. They wouldn't get the new tags, so the jquery stuff wouldn't touch them.
This should be safe even if you're not currently storing times in UTC, because by pure luck the server's time zone is behind UTC - so there would never be an awkward N-hour window during which you couldn't tell whether a given timestamp was pre- or post-cutover.
After running like this for a few months, you could quietly withdraw the profile time offset preference. Any request unaccompanied by an offset cookie could then get any pre-cutover timestamps rendered as raw server times with "PST" stuck on the end. Nobody (not even me) is going to care about the difference between PST and PDT for months-old comments.
Finally, you might want to add a profile time zone preference for those few folks who really really want to see their timestamps in something other than their browser's local timezone.
posted by flabdablet at 8:50 AM on March 24, 2013
Timestamps with post-cutover values would be sent with a suitable tag to make an accompanying jquery snippet treat them as UTC values in need of local munging. Because all such conversions happen client-side, done by browsers that already know their own current offset from UTC, you wouldn't need any server-size time zone processing at all.
Pre-cutover timestamps could be rendered exactly the way you're already doing them. They wouldn't get the new tags, so the jquery stuff wouldn't touch them.
This should be safe even if you're not currently storing times in UTC, because by pure luck the server's time zone is behind UTC - so there would never be an awkward N-hour window during which you couldn't tell whether a given timestamp was pre- or post-cutover.
After running like this for a few months, you could quietly withdraw the profile time offset preference. Any request unaccompanied by an offset cookie could then get any pre-cutover timestamps rendered as raw server times with "PST" stuck on the end. Nobody (not even me) is going to care about the difference between PST and PDT for months-old comments.
Finally, you might want to add a profile time zone preference for those few folks who really really want to see their timestamps in something other than their browser's local timezone.
posted by flabdablet at 8:50 AM on March 24, 2013
It's just occurred to me that with the proposed pre-cutover/post-cutover rendering logic in place and tested, you could then run some kind of revisionist adjustment process that walks backward through old data UTC-izing timestamps as it goes, while simultaneously modifying the cutover epoch so that the main service process continues to generate self-consistent pages.
You would need a table of historical Daylight Saving cut-in and cut-out times to make that work accurately, but because you're only ever adjusting by one of UTC-PST or UTC-PDT you still wouldn't need to do anything like full server-side time zone processing.
posted by flabdablet at 8:59 AM on March 24, 2013
You would need a table of historical Daylight Saving cut-in and cut-out times to make that work accurately, but because you're only ever adjusting by one of UTC-PST or UTC-PDT you still wouldn't need to do anything like full server-side time zone processing.
posted by flabdablet at 8:59 AM on March 24, 2013
And just to be perfectly clear, all you'd need to do with a profile timezone preference is stuff it as-is into each generated page somewhere that the jquery time stamp adjuster could find it; you still wouldn't need any server-side time zone arithmetic.
posted by flabdablet at 9:04 AM on March 24, 2013
posted by flabdablet at 9:04 AM on March 24, 2013
Wait, we're supposed to adjust our local time settings when Daylight time starts and stops? How did I not notice?
...Oh. Because I live in the same time zone as the server.
Man. This invisible backpack has stuff in it I never dreamed of.
posted by reprise the theme song and roll the credits at 9:09 AM on March 24, 2013 [18 favorites]
...Oh. Because I live in the same time zone as the server.
Man. This invisible backpack has stuff in it I never dreamed of.
posted by reprise the theme song and roll the credits at 9:09 AM on March 24, 2013 [18 favorites]
Nobody (not even me) is going to care about the difference between PST and PDT for months-old comments.
I don't understand the specifics of how this works on the back end but I know the userbase quite well and I can assure you that this is not the case. In IRL threads specifically this is a thing people would notice.
posted by jessamyn (staff) at 9:12 AM on March 24, 2013 [2 favorites]
I don't understand the specifics of how this works on the back end but I know the userbase quite well and I can assure you that this is not the case. In IRL threads specifically this is a thing people would notice.
posted by jessamyn (staff) at 9:12 AM on March 24, 2013 [2 favorites]
flabdablet, is a there a specific reason you want the timestamps to be accurate?
I do not intend snark or sarcasm with this question.
And I do not intend snark or sarcasm by answering that I want it mainly because it is clearly the Right Thing, and I've always thought of MeFi as one of the places where the Right Thing eventually happens.
Also I was just disconcerted again, as I am roughly twice every six months, to notice myself posting from the future.
posted by flabdablet at 9:13 AM on March 24, 2013
I do not intend snark or sarcasm with this question.
And I do not intend snark or sarcasm by answering that I want it mainly because it is clearly the Right Thing, and I've always thought of MeFi as one of the places where the Right Thing eventually happens.
Also I was just disconcerted again, as I am roughly twice every six months, to notice myself posting from the future.
posted by flabdablet at 9:13 AM on March 24, 2013
It'll work right as long as you live in a location with the same DST rule as the server, so basically anywhere in the US that has DST is going to work transparently. In Europe it'll be wrong for a few weeks a year, and in the southern hemisphere (where the daylight saving time change is in the opposite direction) you have to correct it or it's wrong for more than half the year.
posted by jepler at 9:13 AM on March 24, 2013
posted by jepler at 9:13 AM on March 24, 2013
If you're talking about converting the existing date stamps, remember that, in local time, the same hour happens twice in a row every autumn. Incrementing post and comment IDs mean that untangling that mess is most likely possible, but I'm sure it's nontrivial.
posted by reprise the theme song and roll the credits at 9:13 AM on March 24, 2013
posted by reprise the theme song and roll the credits at 9:13 AM on March 24, 2013
I can assure you that this is not the case.
I obviously defer to your vastly greater exposure to the user base, but do wish to point out that as things stand at present, the timestamps I see depend on what my profile time offset is set to; and since Daylight Saving in the southern hemisphere is almost-but-not-quite 180° out of phase with that in the northern hemisphere, your southern hemisphere users are all seeing historical timestamps that might be accurate, or might be one or two hours out.
posted by flabdablet at 9:18 AM on March 24, 2013
I obviously defer to your vastly greater exposure to the user base, but do wish to point out that as things stand at present, the timestamps I see depend on what my profile time offset is set to; and since Daylight Saving in the southern hemisphere is almost-but-not-quite 180° out of phase with that in the northern hemisphere, your southern hemisphere users are all seeing historical timestamps that might be accurate, or might be one or two hours out.
posted by flabdablet at 9:18 AM on March 24, 2013
I want it mainly because it is clearly the Right Thing
I get that. There are things that don't affect site functionality that matter to me; this just doesn't happen to be one of them.
posted by insectosaurus at 9:35 AM on March 24, 2013
I get that. There are things that don't affect site functionality that matter to me; this just doesn't happen to be one of them.
posted by insectosaurus at 9:35 AM on March 24, 2013
in local time, the same hour happens twice in a row every autumn
True, and one more good reason for cleaning things up; because as things stand at present, southern-hemisphere users get to see that happening for no apparent reason every spring.
Incrementing post and comment IDs mean that untangling that mess is most likely possible, but I'm sure it's nontrivial.
I believe the proposal I outlined above means that untangling that mess is something that doesn't need to be done by the same processes responsible for serving pages to users; it should be doable in the background by a carefully coded script.
Those "overlapping" hours will in most cases map to unambiguous UTC times, and because the difference between PST/PDT and UTC just happens to be conveniently negative, a process that walks the DB in reverse ID order adjusting timestamps should be able to maintain at all times an unambiguous UTC "fence" later than which any timestamp read from the DB should be treated as UTC.
Because the post and comment IDs do establish an unambiguous ordering, dealing with the overlapping times is not as hard as you might first think: walking strictly backward, you'd flip from doing PST-to-UTC conversion (add eight hours) to PDT-to-UTC (add seven hours) whenever you encounter a timestamp (a) more than an hour earlier than the applicable daylight-saving-end time or (b) later than the unadjusted value of the last one already processed.
The only time this could possibly get a conversion wrong is when no apparent time reversals do actually occur within an hour of daylight saving ending. However, without explicit timezone information stored in the DB (which I'm gathering there isn't) then in that case there is simply not enough information available to decide whether a given event occurred at 1:xx:xx AM PST or 1:xx:xx AM PDT, and an arbitrary assumption of PST therefore looks pretty harmless.
posted by flabdablet at 10:09 AM on March 24, 2013
True, and one more good reason for cleaning things up; because as things stand at present, southern-hemisphere users get to see that happening for no apparent reason every spring.
Incrementing post and comment IDs mean that untangling that mess is most likely possible, but I'm sure it's nontrivial.
I believe the proposal I outlined above means that untangling that mess is something that doesn't need to be done by the same processes responsible for serving pages to users; it should be doable in the background by a carefully coded script.
Those "overlapping" hours will in most cases map to unambiguous UTC times, and because the difference between PST/PDT and UTC just happens to be conveniently negative, a process that walks the DB in reverse ID order adjusting timestamps should be able to maintain at all times an unambiguous UTC "fence" later than which any timestamp read from the DB should be treated as UTC.
Because the post and comment IDs do establish an unambiguous ordering, dealing with the overlapping times is not as hard as you might first think: walking strictly backward, you'd flip from doing PST-to-UTC conversion (add eight hours) to PDT-to-UTC (add seven hours) whenever you encounter a timestamp (a) more than an hour earlier than the applicable daylight-saving-end time or (b) later than the unadjusted value of the last one already processed.
The only time this could possibly get a conversion wrong is when no apparent time reversals do actually occur within an hour of daylight saving ending. However, without explicit timezone information stored in the DB (which I'm gathering there isn't) then in that case there is simply not enough information available to decide whether a given event occurred at 1:xx:xx AM PST or 1:xx:xx AM PDT, and an arbitrary assumption of PST therefore looks pretty harmless.
posted by flabdablet at 10:09 AM on March 24, 2013
....Meanwhile, I'm sitting here thinking, "wait, we can change the timestamp settings? I had no idea."
posted by EmpressCallipygos at 10:20 AM on March 24, 2013 [3 favorites]
posted by EmpressCallipygos at 10:20 AM on March 24, 2013 [3 favorites]
I've always thought of MeFi as one of the places where the Right Thing eventually happens.
The arc of the MetaFilter universe bends towards justice, but sometimes it arrives an hour late. Or an hour early. Depends on where you live.
posted by benito.strauss at 10:23 AM on March 24, 2013 [9 favorites]
The arc of the MetaFilter universe bends towards justice, but sometimes it arrives an hour late. Or an hour early. Depends on where you live.
posted by benito.strauss at 10:23 AM on March 24, 2013 [9 favorites]
I think it's fine to theorize about what shifting timezone calculations to the client side might look like. But keep in mind we have a wide range of clients connecting to MetaFilter. To me, part of doing timezone calculations right is having one method that works for everyone no matter how they're browsing MetaFilter. I don't want two settings in preferences—one legacy offset and one timezone. I don't want to trade one sub-optimal system for another. If we're going to go through the effort of fixing this minor annoyance, we'll do it on the server side. That might seem old-fashioned, but this is MetaFilter.
Newer versions of both ColdFusion and SQL Server have some better timezone tools for us. If we decide to go through the effort of moving to these newer versions, the timezone project becomes less of a hassle. I'm sure the timezone issue will play a part in our decision about whether or not to upgrade.
So this is on our someday list. It's definitely something I've wanted to do for a long time, but I'm not the only one making decisions about where we spend our limited resources.
posted by pb (staff) at 10:28 AM on March 24, 2013
Newer versions of both ColdFusion and SQL Server have some better timezone tools for us. If we decide to go through the effort of moving to these newer versions, the timezone project becomes less of a hassle. I'm sure the timezone issue will play a part in our decision about whether or not to upgrade.
So this is on our someday list. It's definitely something I've wanted to do for a long time, but I'm not the only one making decisions about where we spend our limited resources.
posted by pb (staff) at 10:28 AM on March 24, 2013
Fair enough.
Do you have any numbers on clients that won't run jquery vs. users in the southern hemisphere?
posted by flabdablet at 10:34 AM on March 24, 2013
Do you have any numbers on clients that won't run jquery vs. users in the southern hemisphere?
posted by flabdablet at 10:34 AM on March 24, 2013
Not on me. The last time I looked we had around 70% of users in the US. That was trending down a little bit so it could be less now.
I know this is an annoyance for you, and I apologize for that. We're using a sub-optimal system, we're aware of it, and we'd like to address it someday.
posted by pb (staff) at 10:36 AM on March 24, 2013
I know this is an annoyance for you, and I apologize for that. We're using a sub-optimal system, we're aware of it, and we'd like to address it someday.
posted by pb (staff) at 10:36 AM on March 24, 2013
Then I'll send this nag back to her own paddock and cease to inflict her on you.
Just out of interest, when was the last time you did something that involved editing fourteen years' worth of existing DB content, and how long did that take?
posted by flabdablet at 10:43 AM on March 24, 2013
Just out of interest, when was the last time you did something that involved editing fourteen years' worth of existing DB content, and how long did that take?
posted by flabdablet at 10:43 AM on March 24, 2013
Just out of interest, when was the last time you did something that involved editing fourteen years' worth of existing DB content, and how long did that take?
I think you may have missed the "pb is on vacation" part of my comment. If you could save "just out of interest" questions for a later time, that would be great.
posted by jessamyn (staff) at 10:50 AM on March 24, 2013
I think you may have missed the "pb is on vacation" part of my comment. If you could save "just out of interest" questions for a later time, that would be great.
posted by jessamyn (staff) at 10:50 AM on March 24, 2013
when was the last time you did something that involved editing fourteen years' worth of existing DB content, and how long did that take?
A couple small projects come to mind and they took weeks-to-months of planning and days to implement, then a couple weeks after to do bug fixes.
Changing the site to support the over 170 timezone rules is non-trivial, and something we will do someday, but it's not a huge priority, even though I know it's a drag a couple times a year for a chunk of the userbase.
posted by mathowie (staff) at 10:51 AM on March 24, 2013 [1 favorite]
A couple small projects come to mind and they took weeks-to-months of planning and days to implement, then a couple weeks after to do bug fixes.
Changing the site to support the over 170 timezone rules is non-trivial, and something we will do someday, but it's not a huge priority, even though I know it's a drag a couple times a year for a chunk of the userbase.
posted by mathowie (staff) at 10:51 AM on March 24, 2013 [1 favorite]
Changing the site to support the over 170 timezone rules is non-trivial
Yeah, time-related code is a bitch. That's why I thought I'd float the idea of handling the vast bulk of it client-side, which would save you a hell of a lot of work. But if timestamps are not among the things you're willing to let degrade some when JS isn't available, I guess it's work you'd need to do.
it's a drag a couple times a year for a chunk of the userbase
Jessamyn mentioned earlier that you've got some IRL users who would object to timestamps being presented with an hour-wrong timezone code even on months-old items, so I'll just draw to your attention that when a southern hemisphere user has adjusted the server time offset profile preference to show correct timestamps on current items, for most of the year the timestamps on half the old stuff will be two hours out.
In periods like right now, where your daylight saving has recently started but mine hasn't yet stopped, I see the vast majority of old timestamps either an hour too early or an hour too late. So it's actually a tad annoying for most of the year, and I'm glad it's actually on the list of things to fix even if fairly low down.
If you could save "just out of interest" questions for a later time, that would be great.
Sure, no problem. I'm all done - close up at will.
posted by flabdablet at 11:23 AM on March 24, 2013
Yeah, time-related code is a bitch. That's why I thought I'd float the idea of handling the vast bulk of it client-side, which would save you a hell of a lot of work. But if timestamps are not among the things you're willing to let degrade some when JS isn't available, I guess it's work you'd need to do.
it's a drag a couple times a year for a chunk of the userbase
Jessamyn mentioned earlier that you've got some IRL users who would object to timestamps being presented with an hour-wrong timezone code even on months-old items, so I'll just draw to your attention that when a southern hemisphere user has adjusted the server time offset profile preference to show correct timestamps on current items, for most of the year the timestamps on half the old stuff will be two hours out.
In periods like right now, where your daylight saving has recently started but mine hasn't yet stopped, I see the vast majority of old timestamps either an hour too early or an hour too late. So it's actually a tad annoying for most of the year, and I'm glad it's actually on the list of things to fix even if fairly low down.
If you could save "just out of interest" questions for a later time, that would be great.
Sure, no problem. I'm all done - close up at will.
posted by flabdablet at 11:23 AM on March 24, 2013
If anyone wants to play with a greasemonkey solution, it's possible to generate correct times in Javascript without knowing anything about timezones, just by comparing server time to browser time. As it happens, server time is kindly provided to us at the top of each page.
For example, no matter what offset I choose in my Mefi preferences, this javascript will correct the comment times in a thread to show my correct local time:
If you were going to do this as an official progressive enhancement instead of a greasemonkey thing (which I understand you're not) the clean way to do it might be to wrap things like "12:51 PM" and "March 24" in tags like <span servertime='1364148878317' format='%h:%m %x'>12:51 PM</span>. Then a bit of jquery at the end could calculate the server-browser offset and reliably replace all the servertime tags with just a few lines of code -- and if it didn't run for whatever reason, things would stay just like they are now.
posted by jhc at 11:26 AM on March 24, 2013
For example, no matter what offset I choose in my Mefi preferences, this javascript will correct the comment times in a thread to show my correct local time:
var offsetMinutes = (Date.parse($('p.head').text()) - Date.now())/1000/60;
$('.smallcopy a').each(function(){
if(m = this.innerHTML.match(/^(\d+):(\d+) (AM|PM)/)){
var newMinutes = ((m[1]%12)*60 + m[2]|0 + (m[3]=='PM'?12*60:0) - offsetMinutes) % (24*60);
while(newMinutes < 0)
newMinutes += 24*60;
var newHour = (newMinutes/60|0)%12;
if(newHour==0)
newHour=12;
this.innerHTML = newHour+":"+("0"+(newMinutes % 60)).slice(-2)+" "+(newMinutes > 12*60 ? 'PM':'AM');
}
});
I included the whole thing so you can paste it into the web inspector and run it yourself if you want to see the magic, but the interesting bit is offsetMinutes = (Date.parse($('p.head').text()) - Date.now())/1000/60, which calculates how many minutes wrong the times shown on the page are. The rest is annoying details to figure out what each comment time should be given the offset. (And of course this doesn't fix the dates if we cross midnight.)If you were going to do this as an official progressive enhancement instead of a greasemonkey thing (which I understand you're not) the clean way to do it might be to wrap things like "12:51 PM" and "March 24" in tags like <span servertime='1364148878317' format='%h:%m %x'>12:51 PM</span>. Then a bit of jquery at the end could calculate the server-browser offset and reliably replace all the servertime tags with just a few lines of code -- and if it didn't run for whatever reason, things would stay just like they are now.
posted by jhc at 11:26 AM on March 24, 2013
(On reflection, that one-liner to calculate the offset will only be accurate for posts made near the present, not necessarily for old posts made at a different part of the year if you're on a different daylight savings schedule. But it's still a neat hack.)
posted by jhc at 11:30 AM on March 24, 2013
posted by jhc at 11:30 AM on March 24, 2013
That's inspiring, and I withdraw the request to close this up.
I'm off to bed now (it's just coming up to 6am where I am) but tomorrow I intend to have a crack at a greasemonkey script that converts every "HH:MM [A|P]M on Month DD (YYYY)?" timestamp on the page to UTC based on offsetMinutes and the official DST tables for PDT and PST (including the backwards-walking logic sketched above for dealing with the overlapped hour), then redisplays them as corrected time+date stamps in the browser's own time zone.
If it works, I will of course let anybody else ride my nag wherever they like.
posted by flabdablet at 12:06 PM on March 24, 2013
I'm off to bed now (it's just coming up to 6am where I am) but tomorrow I intend to have a crack at a greasemonkey script that converts every "HH:MM [A|P]M on Month DD (YYYY)?" timestamp on the page to UTC based on offsetMinutes and the official DST tables for PDT and PST (including the backwards-walking logic sketched above for dealing with the overlapped hour), then redisplays them as corrected time+date stamps in the browser's own time zone.
If it works, I will of course let anybody else ride my nag wherever they like.
posted by flabdablet at 12:06 PM on March 24, 2013
....Meanwhile, I'm sitting here thinking, "wait, we can change the timestamp settings? I had no idea."
Yeah, I've just always assumed the site's in Pacific Time and that's that. I suppose if I were regularly up at 2am, it would bother me that the date changed over two hours late (though it doesn't bother me when I'm up at midnight and it doesn't), so perhaps it's more irritating to people in Asia, where the date is wrong a lot of the time.
posted by hoyland at 12:07 PM on March 24, 2013
Yeah, I've just always assumed the site's in Pacific Time and that's that. I suppose if I were regularly up at 2am, it would bother me that the date changed over two hours late (though it doesn't bother me when I'm up at midnight and it doesn't), so perhaps it's more irritating to people in Asia, where the date is wrong a lot of the time.
posted by hoyland at 12:07 PM on March 24, 2013
I use this simple metric, myself, to do manual conversions:
* Stuff that is posted is from the past.
* Stuff that isn't posted yet is from the future.
posted by dhartung at 12:45 PM on March 24, 2013 [3 favorites]
* Stuff that is posted is from the past.
* Stuff that isn't posted yet is from the future.
posted by dhartung at 12:45 PM on March 24, 2013 [3 favorites]
I've connected my Delorean to my desktop (there's a USB port on the Delorean just under the flux capacitor, you've probably not noticed it). It's a noisy solution but it works.
posted by HuronBob at 12:48 PM on March 24, 2013
posted by HuronBob at 12:48 PM on March 24, 2013
This is just to say, I wasn't snarking about the invisible backpack. This post reminded me that everyone faces problems - some of them are the same ones I have, some of them are ones I don't have, and some of them are problems I don't even know exist.
Metafilter, over the years, has helped me to be more understanding of people whose experiences are different from my own.
Thank you. All of you.
posted by reprise the theme song and roll the credits at 1:33 PM on March 24, 2013 [5 favorites]
Metafilter, over the years, has helped me to be more understanding of people whose experiences are different from my own.
Thank you. All of you.
posted by reprise the theme song and roll the credits at 1:33 PM on March 24, 2013 [5 favorites]
I just assume that all users post at Beer O'Clock or Miller Time or Coffee Time or even Hammer Time.
posted by GenjiandProust at 3:21 PM on March 24, 2013 [2 favorites]
posted by GenjiandProust at 3:21 PM on March 24, 2013 [2 favorites]
Actually though, what I really want is not accurate timestamps for my current location, but timestamps from the perspective of the person commenting. Like
posted by jhc at 3:32 PM on March 24, 2013 [3 favorites]
Happy new year!This is more like a unicorn than a pony. But man, as long as we're having a global conversation it would be sweet to see it that way. Kind of like one of those scenes from a movie where people around the world are watching the same thing happen on TV, and then someone says something particularly clever on a website and they all cheer and hug each other ...
posted 7 minutes ago by reveler in New Zealand at 12:01 AM local time on January 1 [+] [!]
Aren't you a little early?
posted 6 minutes ago by new here in Ontario at 7:02 AM local time on December 31 [+] [!]
Way to rub it in.
posted 3 minutes ago by insomiac in Hawaii at 2:05 AM local time on December 31 [+] [!]
posted by jhc at 3:32 PM on March 24, 2013 [3 favorites]
I always post from the future. I've said too much. Please forget you will have read this.
posted by It's Raining Florence Henderson at 3:35 PM on March 24, 2013 [3 favorites]
posted by It's Raining Florence Henderson at 3:35 PM on March 24, 2013 [3 favorites]
pb: "Complicating things is the environment we're running in, Cold Fusion 9... I think I've described it as trying to re-build the foundation of a house while you're still living in it. If I could go back to 1999 and make different choices for MetaFilter, I definitely would. "
I'd love to talk to you about reorienting your content solutions to a next gen Big Data platform backed by Node.jython and with cloud sharding or something. Here's my card.
posted by Riki tiki at 3:36 PM on March 24, 2013 [1 favorite]
I'd love to talk to you about reorienting your content solutions to a next gen Big Data platform backed by Node.jython and with cloud sharding or something. Here's my card.
posted by Riki tiki at 3:36 PM on March 24, 2013 [1 favorite]
Stuff that isn't posted yet is from the future.Not yet it's not.
posted by Flunkie at 3:48 PM on March 24, 2013
Please forget you will have read this.
Too early, I already will have hadding did so (cite).
posted by benito.strauss at 3:59 PM on March 24, 2013 [4 favorites]
Too early, I already will have hadding did so (cite).
posted by benito.strauss at 3:59 PM on March 24, 2013 [4 favorites]
Well, I've only done this once before...
posted by maryr at 8:48 PM on March 24, 2013 [1 favorite]
posted by maryr at 8:48 PM on March 24, 2013 [1 favorite]
Surely, if time travel were possible, it would have been become so some time in the future and at least one person would have brought it back to us and made it possible now as well (if only to reap the undoubtedly huge financial reward for becoming the first person to make it possible). Therefore, as this hasn't happened, I observe that time travel must be impossible.
posted by dg at 9:07 PM on March 24, 2013
posted by dg at 9:07 PM on March 24, 2013
A possibly-relevant note for handling the conversion client-side is that HTML5 defines date and time data types.
posted by XMLicious at 9:50 PM on March 24, 2013
posted by XMLicious at 9:50 PM on March 24, 2013
... at least one person would have brought it back to us and made it possible now as well. Therefore, as this hasn't happened ...
Why do you thinkwe they would let you know?
posted by benito.strauss at 10:10 PM on March 24, 2013
Why do you think
posted by benito.strauss at 10:10 PM on March 24, 2013
Well, my thinking was that the benefit would be from somehow selling the technology but my post-click realisation was that much more profit could be made by betting on past sports events occurring in the future, so maybe impossible is too strong a word...
posted by dg at 11:01 PM on March 24, 2013
posted by dg at 11:01 PM on March 24, 2013
The effect of time travel on the price of securities.
posted by medusa at 4:23 AM on March 25, 2013 [1 favorite]
posted by medusa at 4:23 AM on March 25, 2013 [1 favorite]
Time zones can only be stored as fractal representations of the time cube. Imagine rotating a 7-dimensional cube along the circumference of an 18 axis non-Euclidean sphere, then you'll start to understand why it's easier to just ignore time completely!
posted by blue_beetle at 5:21 AM on March 25, 2013
posted by blue_beetle at 5:21 AM on March 25, 2013
I'm not sure if this is just a riff, or a serious question.
For whatever reason, everything I see displayed, as far as when things are posted, is in West coast time.
There's probably a way I can change that, but I just got over it. It's such a non-hassle it's not even worth the two clicks or whatever it would take to reset.
If we could try to keep the focus on the relative mediocrity that would be a Jessamyn on banjolele, and Cortex on ukulele alternative folk duo, then we are doing something meaningful here.
posted by timsteil at 5:41 AM on March 25, 2013
For whatever reason, everything I see displayed, as far as when things are posted, is in West coast time.
There's probably a way I can change that, but I just got over it. It's such a non-hassle it's not even worth the two clicks or whatever it would take to reset.
If we could try to keep the focus on the relative mediocrity that would be a Jessamyn on banjolele, and Cortex on ukulele alternative folk duo, then we are doing something meaningful here.
posted by timsteil at 5:41 AM on March 25, 2013
The only time this could possibly get a conversion wrong is when no apparent time reversals do actually occur within an hour of daylight saving ending.
I did some work on this a little while back, and it turns out to be a bit more complicated. Aside from the instances where the data is simply ambiguous, as you've noted, there are also a few backdated comments, and, worse, several incidents where the Metafilter clock was broken in one way or another and didn't follow PST/PDT. So, assigning time zone information to old timestamps requires some, er, archaeological analysis.
I've actually done that analysis, and I think I've got everything sorted (or, as sorted as it can be given the inherent ambiguities). I'll report my findings if people are interested, and time permitting. (My first effort, during our last discussion of this issue, was not completely right, though.)
posted by stebulus at 7:36 AM on March 25, 2013
I did some work on this a little while back, and it turns out to be a bit more complicated. Aside from the instances where the data is simply ambiguous, as you've noted, there are also a few backdated comments, and, worse, several incidents where the Metafilter clock was broken in one way or another and didn't follow PST/PDT. So, assigning time zone information to old timestamps requires some, er, archaeological analysis.
I've actually done that analysis, and I think I've got everything sorted (or, as sorted as it can be given the inherent ambiguities). I'll report my findings if people are interested, and time permitting. (My first effort, during our last discussion of this issue, was not completely right, though.)
posted by stebulus at 7:36 AM on March 25, 2013
I've actually done that analysis, and I think I've got everything sorted
Oh wait, I never got around to sorting out the old-style anonymous AskMe questions (which have IDs based on their submission time but timestamps based on their approval time). If memory serves, there was one such question which had an impossible timestamp (i.e., a timestamp during an hour which, according to other data, the server skipped in a DST change), and maybe there was other weirdness too.
So, there's still a bit of work to be done on the existing timestamps.
posted by stebulus at 7:48 AM on March 25, 2013
Oh wait, I never got around to sorting out the old-style anonymous AskMe questions (which have IDs based on their submission time but timestamps based on their approval time). If memory serves, there was one such question which had an impossible timestamp (i.e., a timestamp during an hour which, according to other data, the server skipped in a DST change), and maybe there was other weirdness too.
So, there's still a bit of work to be done on the existing timestamps.
posted by stebulus at 7:48 AM on March 25, 2013
You can go to Preferences and change the Time offset.
And, for the record, I want this to be correct because I want to know how long it has been since the last reply.
Knowing the post time in the local timezone of the poster (cf. the unicorn above) would also be interesting, but I'd still like to have the post time in my chosen timezone listed as well.
Then again there's a significant part of me that really does not like Daylight Saving time or even time zones and wants everything to be listed in UTC plus maybe a gps-aided local solar time. Growing up in Michigan (which is in Eastern time zone) and spending a fair amount of summers in the western part of the state will do that to you, I guess. In the summer solar noon nears 2 p.m. and sunset pushes 11 p.m.
posted by mountmccabe at 8:35 AM on March 25, 2013
And, for the record, I want this to be correct because I want to know how long it has been since the last reply.
Knowing the post time in the local timezone of the poster (cf. the unicorn above) would also be interesting, but I'd still like to have the post time in my chosen timezone listed as well.
Then again there's a significant part of me that really does not like Daylight Saving time or even time zones and wants everything to be listed in UTC plus maybe a gps-aided local solar time. Growing up in Michigan (which is in Eastern time zone) and spending a fair amount of summers in the western part of the state will do that to you, I guess. In the summer solar noon nears 2 p.m. and sunset pushes 11 p.m.
posted by mountmccabe at 8:35 AM on March 25, 2013
Why not just have MeFi (& its kids) run on a Zulu Clock?
After all, it's the same time everywhere all the time anyhow.
posted by mule98J at 10:12 AM on March 25, 2013
After all, it's the same time everywhere all the time anyhow.
posted by mule98J at 10:12 AM on March 25, 2013
I've been saying it for years: we need to switch to Swatch Time.
posted by cortex (staff) at 10:29 AM on March 25, 2013 [1 favorite]
posted by cortex (staff) at 10:29 AM on March 25, 2013 [1 favorite]
It's Hammer time.
Release theKracken Earworm!!
posted by It's Raining Florence Henderson at 11:28 AM on March 25, 2013
Release the
posted by It's Raining Florence Henderson at 11:28 AM on March 25, 2013
I always post from the future. I've said too much. Please forget you will have read this.
I experience time backwards, so I already have, and just now remembered it.
posted by Gygesringtone at 3:16 PM on March 25, 2013
I experience time backwards, so I already have, and just now remembered it.
posted by Gygesringtone at 3:16 PM on March 25, 2013
stebulus, I'm currently messing about with a semi-automated archaeological infodump timestamp analyzer and would definitely be interested in cross-checking my results with yours.
posted by flabdablet at 8:31 AM on April 4, 2013
posted by flabdablet at 8:31 AM on April 4, 2013
I'm working on a script that slurps up the infodump and will ultimately spit out a Javascript function to look up timezone by commentid/postid across mefi/askme/meta/music without causing more sequence anomalies than are actually present in the data, and I'm pretty happy with progress so far.
I've got as far as generating a table that I believe correctly identifies all the server's timezone transitions. After taking those into account, the only things I'm now seeing as out-of-sequence are (a) askme anonyposts (b) a small handful of comments and posts that appear to have had times assigned by hand (c) about a dozen instances where time goes backwards for a minute or two, which look like the typical result of Windows's rather brutal approach to network time sync.
The only major weirdness I've found that stebulus hasn't already mentioned is between 2006-04-20 14:56:30-07 and 2006-04-20 16:07:00-07 where the server appears to have switched briefly to super duper double secret daylight saving time (tz -05). No clue why that would have happened but the mefi comment data says it did and none of the other data disagrees.
My plan for the OOS items is first to attempt to look up an appropriate tz purely by timestamp. If this fails because the timestamp falls inside a DST transition, assign the tz that makes a post appear to have happened as close as possible to its first comment, or a comment appear as little out of sequence as possible.
Once this stuff is all clean and working I'll post it somewhere online. Until then, here's my current mefi-tz table:
tz|starts_at|ends_before
-07|1999-04-04 03:00:00.000|1999-10-31 02:00:00.000
-08|1999-10-31 01:00:00.000|2000-04-02 02:00:00.000
-07|2000-04-02 03:00:00.000|2000-10-29 02:07:30.000
-08|2000-10-29 01:07:30.000|2001-04-01 02:00:00.000
-07|2001-04-01 03:00:00.000|2001-10-28 02:00:00.000
-08|2001-10-28 01:00:00.000|2002-04-07 02:00:00.000
-07|2002-04-07 03:00:00.000|2002-10-27 02:00:00.000
-08|2002-10-27 01:00:00.000|2003-04-06 02:00:00.000
-07|2003-04-06 03:00:00.000|2003-10-26 02:00:00.000
-08|2003-10-26 01:00:00.000|2004-04-04 02:00:00.000
-07|2004-04-04 03:00:00.000|2004-10-31 02:00:00.000
-08|2004-10-31 01:00:00.000|2005-04-03 02:00:00.000
-07|2005-04-03 03:00:00.000|2005-10-30 02:00:00.000
-08|2005-10-30 01:00:00.000|2006-04-02 02:00:00.000
-07|2006-04-02 03:00:00.000|2006-04-20 14:56:30.000
-05|2006-04-20 16:56:30.000|2006-04-20 18:07:00.000
-07|2006-04-20 16:07:00.000|2006-10-29 02:00:00.000
-08|2006-10-29 01:00:00.000|2007-03-25 23:11:17.000
-07|2007-03-26 00:11:17.000|2007-03-26 04:16:31.040
-08|2007-03-26 03:16:31.039|2007-04-01 02:00:00.000
-07|2007-04-01 03:00:00.000|2007-10-28 02:00:00.000
-08|2007-10-28 01:00:00.000|2007-10-28 10:06:53.590
-07|2007-10-28 11:06:53.590|2007-11-04 10:06:00.590
-08|2007-11-04 09:06:00.589|2008-03-09 12:33:51.983
-07|2008-03-09 13:33:51.982|2008-11-02 02:00:00.000
-08|2008-11-02 01:00:00.000|2009-03-08 02:00:00.000
-07|2009-03-08 03:00:00.000|2009-11-01 02:00:00.000
-08|2009-11-01 01:00:00.000|2010-03-14 02:00:00.000
-07|2010-03-14 03:00:00.000|2010-11-07 02:00:00.000
-08|2010-11-07 01:00:00.000|2011-03-13 02:00:51.137
-07|2011-03-13 03:00:51.137|2011-11-06 02:00:00.000
-08|2011-11-06 01:00:00.000|2012-03-11 02:00:00.000
-07|2012-03-11 03:00:00.000|2012-11-04 02:00:00.000
-08|2012-11-04 01:00:00.000|2013-03-10 02:00:00.000
-07|2013-03-10 03:00:00.000|2013-11-03 02:00:00.000
posted by flabdablet at 8:49 PM on April 6, 2013
I've got as far as generating a table that I believe correctly identifies all the server's timezone transitions. After taking those into account, the only things I'm now seeing as out-of-sequence are (a) askme anonyposts (b) a small handful of comments and posts that appear to have had times assigned by hand (c) about a dozen instances where time goes backwards for a minute or two, which look like the typical result of Windows's rather brutal approach to network time sync.
The only major weirdness I've found that stebulus hasn't already mentioned is between 2006-04-20 14:56:30-07 and 2006-04-20 16:07:00-07 where the server appears to have switched briefly to super duper double secret daylight saving time (tz -05). No clue why that would have happened but the mefi comment data says it did and none of the other data disagrees.
My plan for the OOS items is first to attempt to look up an appropriate tz purely by timestamp. If this fails because the timestamp falls inside a DST transition, assign the tz that makes a post appear to have happened as close as possible to its first comment, or a comment appear as little out of sequence as possible.
Once this stuff is all clean and working I'll post it somewhere online. Until then, here's my current mefi-tz table:
tz|starts_at|ends_before
-07|1999-04-04 03:00:00.000|1999-10-31 02:00:00.000
-08|1999-10-31 01:00:00.000|2000-04-02 02:00:00.000
-07|2000-04-02 03:00:00.000|2000-10-29 02:07:30.000
-08|2000-10-29 01:07:30.000|2001-04-01 02:00:00.000
-07|2001-04-01 03:00:00.000|2001-10-28 02:00:00.000
-08|2001-10-28 01:00:00.000|2002-04-07 02:00:00.000
-07|2002-04-07 03:00:00.000|2002-10-27 02:00:00.000
-08|2002-10-27 01:00:00.000|2003-04-06 02:00:00.000
-07|2003-04-06 03:00:00.000|2003-10-26 02:00:00.000
-08|2003-10-26 01:00:00.000|2004-04-04 02:00:00.000
-07|2004-04-04 03:00:00.000|2004-10-31 02:00:00.000
-08|2004-10-31 01:00:00.000|2005-04-03 02:00:00.000
-07|2005-04-03 03:00:00.000|2005-10-30 02:00:00.000
-08|2005-10-30 01:00:00.000|2006-04-02 02:00:00.000
-07|2006-04-02 03:00:00.000|2006-04-20 14:56:30.000
-05|2006-04-20 16:56:30.000|2006-04-20 18:07:00.000
-07|2006-04-20 16:07:00.000|2006-10-29 02:00:00.000
-08|2006-10-29 01:00:00.000|2007-03-25 23:11:17.000
-07|2007-03-26 00:11:17.000|2007-03-26 04:16:31.040
-08|2007-03-26 03:16:31.039|2007-04-01 02:00:00.000
-07|2007-04-01 03:00:00.000|2007-10-28 02:00:00.000
-08|2007-10-28 01:00:00.000|2007-10-28 10:06:53.590
-07|2007-10-28 11:06:53.590|2007-11-04 10:06:00.590
-08|2007-11-04 09:06:00.589|2008-03-09 12:33:51.983
-07|2008-03-09 13:33:51.982|2008-11-02 02:00:00.000
-08|2008-11-02 01:00:00.000|2009-03-08 02:00:00.000
-07|2009-03-08 03:00:00.000|2009-11-01 02:00:00.000
-08|2009-11-01 01:00:00.000|2010-03-14 02:00:00.000
-07|2010-03-14 03:00:00.000|2010-11-07 02:00:00.000
-08|2010-11-07 01:00:00.000|2011-03-13 02:00:51.137
-07|2011-03-13 03:00:51.137|2011-11-06 02:00:00.000
-08|2011-11-06 01:00:00.000|2012-03-11 02:00:00.000
-07|2012-03-11 03:00:00.000|2012-11-04 02:00:00.000
-08|2012-11-04 01:00:00.000|2013-03-10 02:00:00.000
-07|2013-03-10 03:00:00.000|2013-11-03 02:00:00.000
posted by flabdablet at 8:49 PM on April 6, 2013
between 2006-04-20 14:56:30-07 and 2006-04-20 16:07:00-07 where the server appears to have switched briefly to super duper double secret daylight saving time (tz -05). No clue why that would have happened
Clock glitch! See 1 and 2.
posted by stebulus at 12:43 PM on April 7, 2013
Clock glitch! See 1 and 2.
posted by stebulus at 12:43 PM on April 7, 2013
-08|2006-10-29 01:00:00.000|2007-03-25 23:11:17.000
-07|2007-03-26 00:11:17.000|2007-03-26 04:16:31.040
-08|2007-03-26 03:16:31.039|2007-04-01 02:00:00.000
-07|2007-04-01 03:00:00.000|2007-10-28 02:00:00.000
I think this part is wrong. The events as I understand them:
-07|2007-03-26 00:11:17.000|2007-03-26 04:16:31.040
-08|2007-03-26 03:16:31.039|2007-04-01 02:00:00.000
-07|2007-04-01 03:00:00.000|2007-10-28 02:00:00.000
I think this part is wrong. The events as I understand them:
- 2007-03-11: DST starts, following the new rules[Energy Policy Act 2005, §110], so the clock jumps from UTC-8 to UTC-7. A MeTa is opened to complain, as is our way.
- 2007-03-25 to 26: Almost 24 hours of downtime[MeTa, status], starting at 03-25 01:27 and ending at 03-26 00:10 (according to the timestamps). The servers are entirely replaced, and the new servers come up in UTC-6 for some reason. Matt fixes it at about 04:16 (or 03:16, as it became), making it UTC-7 again.
- 2007-04-01: The new servers, erroneously following the old DST rules, change from UTC-7 to UTC-6, at 02:00/03:00. The clock is set back to UTC-7 at 21:48/20:48. The only record of the incident (outside the infodump) is a MeTa comment a few days later.
Your archaeology is superior!
I have added those transitions to my script, and the resulting table section now looks like this:
-08|2006-10-29 01:00:00.000|2007-03-11 02:00:00.000
-07|2007-03-11 03:00:00.000|2007-03-25 23:10:00.000
-06|2007-03-26 00:10:00.000|2007-03-26 04:16:31.040
-07|2007-03-26 03:16:31.039|2007-04-01 02:00:00.000
-06|2007-04-01 03:00:00.000|2007-04-01 21:48:00.000
-07|2007-04-01 20:48:00.000|2007-10-28 02:00:00.000
After making this change, the scanning part of the script now reveals no impossible times or unanticipated time reversals in 2007 for askme, mefi, meta or music comments; I'd previously been overlooking one at 2007-04-01 20:56:03.623 for comment 1639323. Thank you!
posted by flabdablet at 6:58 PM on April 7, 2013
I have added those transitions to my script, and the resulting table section now looks like this:
-08|2006-10-29 01:00:00.000|2007-03-11 02:00:00.000
-07|2007-03-11 03:00:00.000|2007-03-25 23:10:00.000
-06|2007-03-26 00:10:00.000|2007-03-26 04:16:31.040
-07|2007-03-26 03:16:31.039|2007-04-01 02:00:00.000
-06|2007-04-01 03:00:00.000|2007-04-01 21:48:00.000
-07|2007-04-01 20:48:00.000|2007-10-28 02:00:00.000
After making this change, the scanning part of the script now reveals no impossible times or unanticipated time reversals in 2007 for askme, mefi, meta or music comments; I'd previously been overlooking one at 2007-04-01 20:56:03.623 for comment 1639323. Thank you!
posted by flabdablet at 6:58 PM on April 7, 2013
I've got up to cross-checking comment times against post times, and I'm seeing quite a few posts timestamped after their first comment (e.g. AskMe 22191). What's going on there? Do mod edits give things new timestamps?
posted by flabdablet at 7:19 AM on April 14, 2013
posted by flabdablet at 7:19 AM on April 14, 2013
That question was back when the anon feature was new and I think there was some hack to make anon questions show up when they were approved and not technically when they were posted to the queue, if that makes sense. If you're seeing it with non-anon questions, toss in some links, otherwise you'd have to email us and ask pb what he specifically did with anon questions back then.
posted by jessamyn (staff) at 7:28 AM on April 14, 2013
posted by jessamyn (staff) at 7:28 AM on April 14, 2013
I'm certainly seeing the anon posts completely out of sequence with the regular run of AskMe posts, but for most of them I'm not seeing a post timestamp later than that of the first comment. But it's not just AskMe anon posts doing this - e.g. MeFi 7878, 38900, 39291, 46037, 55360, 74339.
I haven't found any of this kind of weirdness as either cause or consequence of assigning a time zone to a timestamp, so I think I'll just write these off as known mysteries of unknown cause and stop worrying about them.
For anybody still interested, here is what I have so far:
Each line of comment_tz_{askme,mefi,meta,music}.txt shows the first comment ID in a range for which the given timezone should apply to the comment timestamp; the end of each such range is implied by the next line.
post_tz_{askme,mefi,meta,music}.txt do the same thing for post IDs.
The various *-anomalies-*.txt files show sequencing anomalies that the infodump analysis script is currently detecting but has not yet made explicit allowance for, and tz-table.txt is my best guess at a reconstruction of MeFi server clock behavior since 1999.
Once the script is tweaked enough that it's no longer generating anomalies files as a matter of course, I'll run it as a regular cron job so all these things stay pretty much as up to date as the infodump. And after that it will be time to start learning about greasemonkey.
posted by flabdablet at 8:54 AM on April 14, 2013
I haven't found any of this kind of weirdness as either cause or consequence of assigning a time zone to a timestamp, so I think I'll just write these off as known mysteries of unknown cause and stop worrying about them.
For anybody still interested, here is what I have so far:
Each line of comment_tz_{askme,mefi,meta,music}.txt shows the first comment ID in a range for which the given timezone should apply to the comment timestamp; the end of each such range is implied by the next line.
post_tz_{askme,mefi,meta,music}.txt do the same thing for post IDs.
The various *-anomalies-*.txt files show sequencing anomalies that the infodump analysis script is currently detecting but has not yet made explicit allowance for, and tz-table.txt is my best guess at a reconstruction of MeFi server clock behavior since 1999.
Once the script is tweaked enough that it's no longer generating anomalies files as a matter of course, I'll run it as a regular cron job so all these things stay pretty much as up to date as the infodump. And after that it will be time to start learning about greasemonkey.
posted by flabdablet at 8:54 AM on April 14, 2013
You are not logged in, either login or create an account to post comments
posted by jessamyn (staff) at 8:05 AM on March 24, 2013 [1 favorite]