-
My Time Offset is -1 and the Current Forum Time is (presumably) CEST i.e. one hour ahead of UK's summer time (BST). However when I click 'auto detect' the -1 turns to 0 and the times of the latest posts are CEST time. I've tried this in Opera and Chrome with the same effect. My PC clock is showing BST.
Anyone else get this?
-
Correct Time is shown for me.
This is a French server btw but I believe most Europeans are on the same time savings dates?
-
I've not explained myself.
The correct time is showing. However when I go into Profile / Look & Layout and click 'auto detect' to set the Time Offset I should get a -1 because the UK is an hour behind France, but I get a 0. If I save this, the times are then incorrect for my location. I am hypothesising that there is an error with the auto detect function :)
-
Is your computer clock correct, though? That particular code hasn't been changed, and it works by comparing server time with local time.
Interestingly, mine is correct here though I have not touched anything... :/
-
Same here.
-
And since the user profile area does not have timezone configuration (even though it's supported internally), that would presume the server is appropriately configured and uses a timezone setting that is equivalent to Europe/London.
-
I've noticed this also. Depending upon DST here in the US I should be either -5 or -4, but when I hit auto detect it puts zero in instead of -5 or -4. Yes my computers clock is right and also for some strange reason -5 or -4 don't give me the correct time for my time zone.
-
Well, my account states it as -1, which is relative to server time, not to GMT. The server is set to French time, which is GMT(or BST) + 1.
In your case, you will need either -5 or -6 rather than -4 or -5, just the same as any other hosting and any other setup where the server's timezone is different to yours, and different to UTC.
-
My current offset is -8 but the auto detector resets it to zero.
Posted: March 26th, 2012, 12:01 AM
What the hell is loader.js?
Posted: March 26th, 2012, 12:10 AM
Found a merge bug, will report it later.
Posted: March 26th, 2012, 12:11 AM
test
:edit: YAT (yet another test)
-
Ok, it keeps the edited time for the post to merge, but not the post to merge into. So the alleged bug is just normal behavior.
-
What..?
-
Well, my account states it as -1
Nao and other central Europeans cannot test this as they are within the server's time zone, and therefore the offset should be 0.
-
Auto detect is indeed broken here for me too.
-
Auto detect sets my offset to "0" also - should be "-1".
-
Sorry it took so long to explain. And just to note that my account on aeva.noisen.com gets set to the correct time - I mention this in case it is the same server so it can be ruled out.
-
Rewrote the js function. Does it work now?
-
Still being set to 0 for me.
-
Still being set to 0 for me.
Posted: March 26th, 2012, 06:33 PM
Nope, works for me... Advanced my time by two hours. Told me '2'.
-
Still 0 for me too :-/
-
Posted: March 26th, 2012, 06:33 PM
Nope, works for me... Advanced my time by two hours. Told me '2'.
-
I believe I updated the site hours ago.
-
Mine is set to 0 but it's correct.. :whistle:
-
Still being set to 0 for me.
-
Crap...
What should it give you?
Try in Opera maybe? It might be a browser bug...
-
I use Opera, but ethankcvds is right it says "(rev 1509)" in the footer.
-
I update the footer rev number manually.
Let's be clear -- in 99% of all cases, Wedge.org is running the latest rev (dare I even say -- a newer rev, because I do my testing here so it's got uncommitted stuff in it). I just forget to update the rev number here when I commit...
Although it did happen once that I committed, and forgot to upload the committed file here.
:edit: updated. As I said, the files were all up to date. Bed time!
-
My svn update script updates the rev in the footer. You have a copy of it.
-
Hmm yeah, but I have other priorities, known song :)
Hey! Opera 12.00 just went past Chrome in terms of HTML5 support :eheh:
http://html5test.com/index.html
It's the first time in a LONG time that this has happened. It's now at 379 (if you enable websockets in opera:config), versus 375 for Chrome apparently.
Only problem is -- this new version of 12.00 is unusable for me... It's awfully, horribly slow! On a Core i7 machine!! I guess it's not the case everywhere, though.
-
"I update the footer rev number manually." Sorry - take it as a compliment that we naturally thought it would be automated :)
However it is stubbornly staying at 0 - the server time is 07:30 AM and my PC's clock says 06:30.
-
Hopefully, r1517 will solve this.
The reason it was freaking out is because the server timezone wasn't taken into account properly.
-
I'm presuming at the time of posting this that this site is currently running the latest revision if not this post can be ignored.
Still being set to 0 for me.
-
Nao's in bed, it has not been updated yet... especially as the footer says 1516 and I mentioned it was fixed in 1517...
-
I offered Pete FTP access but he'd rather not have it so we have an understanding that I'll try to post his updates asap. Meaning when I'm done updating my local copy ;)
Posted: March 29th, 2012, 01:37 PM
Should be up, now.
-
Just tried again and it is still being set to 0.
-
Yeah, I just came here to point out that date_offset_get() expects a parameter...
http://www.php.net/manual/en/datetime.getoffset.php
But the parameter is created through date_create(), which is never called in Wedge.
I'll leave it to Pete for the rest.
-
The Neverending Story.. :lol:
-
Yep...
Or maybe we just want non-Europeans to shut up and accept the truth for what it is: our system is the One True System... :niark:
-
Yep...
Or maybe we just want non-Europeans to shut up and accept the truth for what it is: our system is the One True System... :niark:
-
Then you have other people claim that their system is the one true system.
Lots of fun.
-
Ugh, I missed that somehow, though oddly it never threw any errors when I ran the code >_>
-
Just don't forget to fix it... It tends to fill the log quickly, with bots visiting the registration link... ;)
(Heck... Maybe we should add a rel="nofollow" to that link...?!)
-
Works for me. It should also be indicated as noindex in the headers too.
-
I'm pretty sure it already is.
-
It's still wrong here now, even though it's been updated >_<
Guess I know what I'm doing today :(
-
If it's not 'wrong' in the SMF codebase, maybe you could look into it and see where you started deviating from their code..?
-
I know exactly when it broke, I broke it when I changed over everything internally to use the proper PHP timezone functions.
-
Hmm... Meaning that their functions are broken? :P
Or just plain hard to use...! If someone like Arantor can't get them to work immediately!
-
Oh, the entire concept of date/time is complicated to get right, and I'd long wondered if I had or not.
That said, I never really wanted to keep the time offset anyway, and long ago started to make changes to move away from it to proper timezone support anyway. Internally it's even handled, too, I just didn't get as far as making a nice UI for it.
-
Okay. :P
(Oh and tell me about complexity. I can barely even read time when giving by an analog clock...)
-
Well, it's going to end up being a dropdown to pick timezones rather than hour-offset. Which also means that India will be represented properly too.
-
:)
-
OK so I implemented the list of timezones. Unlike the admin one which is automatically populated, this one isn't because it does actually need to be shown to users and as such shouldn't have a bajillion entries that are mostly duplicated.
This is compiled off several different sources and should be accurate (and it should work, too) so when the site gets updated, give it a shot.
-
Wouldn't it be easier to forget about timezones, then....? I don't know.
-
No, it really wouldn't.
The server absolutely *has* to have a timezone anyway, and PHP will vomit errors every call to time() and date() amongst other things if you try to call either without a timezone. So if you already have a timezone, you might as well do it properly and be done with it.
The plus side is that if you pick the right region, daylight savings should be handled automagically for you by way of the TZ database.
-
'Kay then.
The code is really on the heavy side though... Here's hoping you won't have to update it!
Server updated to r1528. Including the French word, but I won't commit it for now. I'm OFF to Omega. See you later tonight!
-
I changed mine to Eastern US/Canada but it reverts to UTC-Dublin.......
-
Curious, that part worked for me as expected. Anyway, does it show the right times everywhere? (i.e. it's just a UI problem rather than anything else)
Posted: March 30th, 2012, 03:35 PM
OK, so I think this is a strange bug somewhere in the bowels of things. Timezone identifiers that have an _ in them appear to be broken, but any others work as expected (e.g. if you pick Central European, which is what I tested with, the internal identifier is Europe/Amsterdam, and it works as expected, but Eastern US/Canada is using America/New_York)
Hmm, I think this is a deeper problem with the profile code but I'll look into it.
-
The time is correct everywhere indeed.
-
So it is just a UI matter, that I can look into separately.
-
Nice one :cool: If the server is in the US then there's a period between when the UK goes to savings time and when they do, and for that period the times are wrong. This fix will do away with this issue.
To let others know, in my profile it was listed UTC 0 (Dublin, etc) but I had to save my profile to get away from central European times.
-
The default is UTC Dublin if it has nothing else at all to work with, and there's a bug where if you save it, it may reshow UTC Dublin on the next page load even if it isn't using that actual timezone itself.
-
BTW if a new account is registered the profile shows UTC Dublin, etc but the timestamps are an hour behind BST i.e. my previous post shows as 15:34. I guess this will confuse a lot of brits, irish and portugesers :-/
-
That's because I didn't add on the facility to select timezone on registration, which is the next thing I'm doing, or will be doing once this bloody headache shifts.
Once you select it on registration, there really isn't so much of a problem ;)
-
Cool :)
Have you taken paracetamol? Or maybe you're still dehydrated after your recent exercise?
-
I've taken ibuprofen, and I may still be a touch dehydrated though I've had a lot to drink since yesterday afternoon, will have more though to see if it helps.
Also, actually, there will still be an issue with users who come from other systems, but I may be able to fix that by extending the importer, we'll have to see.
-
It's interesting (to me) that in hospital we always give Paracetamol then Codeine and only an Ibuprofen-type drug after that, but people in their own homes seem to take Ibuprofen as a first line. Clever marketing? Anyway hope it goes away, and ah yes importers! That'll be a pain to test!
-
There are probably several reasons, related to the number/types/severity of side effects of ibuprofen vs paracetamol, users' reaction to it etc. I just went with it because it was cheaper than paracetamol given that I could get generic ibuprofen vs only branded paracetamol. *shrug*
The importers aren't such a pain to test, generally, and with it there's really only so much that can be done - take the server time offset, factor in the user's own offset and look it up against a list of 'most likely' candidates, and with any luck it'll turn out OK.
-
There are probably several reasons, related to the number/types/severity of side effects of ibuprofen vs paracetamol, users' reaction to it etc. I just went with it because it was cheaper than paracetamol given that I could get generic ibuprofen vs only branded paracetamol. *shrug*
How's your food intake been today? I get terrible headaches when I don't bother eating for half a day.
-
Bowl of cereal for breakfast, cheese and tomato sandwich for lunch, will do dinner soon (got up at 10am today so that's about right timewise), all in all nothing out of the ordinary really.
-
/mehas no idea what the difference between paracetamol, codeine and ibuprofen is. So he takes all three at the same time, just to be sure.
-
!!!!!
Essentially they all block different pain receptors to the brain. I remember my doctor once told me I could mix paracetamol and ibuprofen provided I put two hours between each and didn't overdo it.
-
Well I usually take Doliprane or Novacetol, dunno if they're specific to France. Doliprane has paracetamol IIRC, and Novacetol has paracetamol + codeine + something else (can't remember but it's not ibuprofene), and I usually take the Novacetol. I have headaches on a weekly basis and I try not to get accustomed to a brand over another, but I don't think it's that important...
IIRC, ibuprofen just doesn't work for me.
-
If you're getting them regularly, something is wrong. It might be a dehydration thing, it might be improper setup of computer+desk, general neck tension or something else, but if you have them more than occasionally, you should probably look into it...
-
Genetics?
-
It actually is quite rare to be genetically predisposed to 'headaches'. It's where there's pain receptors that are firing for some reason.
-
I don't know.
I don't have that many headaches... My father had more. Then they stopped after a few decades.
In the winter I rarely open my window, too. That may have an influence. Plus, my last headache was a couple of hours after I finally committed a "working" version of reverse post order. May be stress-induced.
-
The basis of UK (and presumably worldwide) pain management: http://en.wikipedia.org/wiki/Pain_ladder
-
[offtopic]
Novacetol = Acide acétylsalicylique , Paracétamol , Codéine
Doliprane = Paracétamol
Aspirine = Acide acétylsalicylique
Paracetamol is a bit more friendly to your stomach then acetylsalicylic acid.
[/offtopc]
-
buy p4r4cetamo1 buy 4sp1r1n buy v14gr4
spam sp4m spam spam sp4m
Hey Pete, doesn't it bother you that the new timezone technique will force all forum users to choose a timezone for all forums they go to...? When in many situations of the past they may have been on the same timezone as the server and not have had anything to do..? Or is a default timezone set depending on their time offset data?
/meis watching Saint Seiya Omega on KeyholeTV right now. Total winner.
-
I have not yet added one on registration, which will default to the server's timezone. It does not bother me one iota that this will be the case, because other systems do this, and since it's only done on registration, users only have to do it once - and it's still more meaningful and logical than setting an offset.
No default is set based on their offset, so there will need to be some aspect of changeover for people here though IIRC it will still use a time offset if they already had one, but in due course I'll remove that and solely rely on the timezone setting. New users will, of course, then fall into having the timezone selector to deal with on registration, and we will need to add something into the importer (as mentioned earlier in this thread)
-
I really can't for the life of me accept this timezone system as it is right now.
I was looking at php.net and everything, and was at a loss. What should I do?
Then I considered several solutions and would like to suggest it.
Just get the whole list of timezones, split them into continents, and offer a select box with continent categories and city names for each (sorted by name).
I'd really rather rely on Wedge asking me to say where my timezone is (Europe > Paris), rather than having to select a timezone based on whatever cities we decided to include in the list...
Heck, we could even simply ask them for their country (okay let me just type 'F' here in the dropdown list... That's it, France...), and then automatically load a list of available timezones for the country (timezone_identifiers_list(DateTimeZone::PER_COUNTRY, $country)). If there's only one, use that, otherwise show a new select box with a timezone list... (requires PHP 5.3, though. But by the time it's released, maybe we could expect it to be installed...)
-
I was looking at php.net and everything, and was at a loss. What should I do?
I'd really rather rely on Wedge asking me to say where my timezone is (Europe > Paris), rather than having to select a timezone based on whatever cities we decided to include in the list...
Consider also that other forums perform just fine having multiple cities grouped together without any problems.Heck, we could even simply ask them for their country (okay let me just type 'F' here in the dropdown list... That's it, France...), and then automatically load a list of available timezones for the country
Have fun with managing that 470-odd list down into the groups you're hoping for, it took me long enough to compile the list I had.
(Sorry for my attitude, I'm tired, achy, pissed off with the weather here and I have other stuff going on out here in RL that's bugging me, like the fact that I'm in the process of taking my name off the house that I bought almost 5 years ago as the place I wanted to spend the rest of my life :()
-
Do you *really* want to put a 470-odd long select list into the *general user area*? It's bad enough having it in the admin area.
Consider also that other forums perform just fine having multiple cities grouped together without any problems.
If you want to do it, go nuts. Ever delving into timezones is one of the (very few) things I've ever regretted taking on with Wedge.
Just keep to the server's timezone, and adjust user settings with the time offset... Voilà. If they ever get diverging hours (because of time savings), they can simply update their account page.The entire situation is a fucking mess, long before we came along, Just remember that whatever you do, you're cleaning up an operation that users will only see on registration and when they delve into their profile, they won't see it the rest of the time.
https://bitbucket.org/pellepim/jstimezonedetect/raw/6c845a1f02b7/detect_timezone.js
This fun little script will try and detect the user's actual time zone. It would be nice to simply run it at registration time, and use it to select a default timezone for the user...
BTW, head to the admin area. I implemented the continent separator into the Manage Server page.Have fun with managing that 470-odd list down into the groups you're hoping for, it took me long enough to compile the list I had.
(Sorry for my attitude, I'm tired, achy, pissed off with the weather here and I have other stuff going on out here in RL that's bugging me, like the fact that I'm in the process of taking my name off the house that I bought almost 5 years ago as the place I wanted to spend the rest of my life :()
-
Actually, it's 580+... I don't know why everyone in their samples, including you, insist on forgetting about that (admittedly very small but still a bit more important than Antarctica), continent called Africa...?
Yes, it is 580+, but there are dozens that are legacy and deprecated.I don't know, never seen that on other forums really.
Just keep to the server's timezone, and adjust user settings with the time offset... Voilà. If they ever get diverging hours (because of time savings), they can simply update their account page.
But I'd like for it to be correct, since everyone else can get it right and I don't see why we can't. I just haven't finished working on it, but hey, I guess I can remove all that and be done with it. I wonder if there's anything else that's a waste of my time working on.I remember that... And for now we'll keep to it. I'd just like to be sure there isn't a better solution here. :)
An improvement to use proper timezones has been requested many times before for SMF but no-one's willing to take it on, because it's a minefield, and until recently SMF has been supporting prior to PHP 5.1 where all the date stuff was properly implemented.
Still, if you're happy with the shitty method, go revert it.
(I, on the other hand, will be going to find a drink to calm the fuck down. I should remember not to go visit certain people to sort out disentangling myself from my old life. Still, that should be dealt with soon enough and I can just start trying to forget the last 10 years.)
-
Actually, Africa IS listed. I see West Central Africa (UTC+1), South Africa Standard Time (UTC+2) plus places like Cairo that are in Africa last I checked.
Yes, it is 580+, but there are dozens that are legacy and deprecated.
XenForo and phpBB do it. Hell, even Windows, Mac OS X and Ubuntu do it.
If you want to revert it, revert it.
There are three solutions: providing a fuck off big list to users that requires minimal work from us but looks ugly (like in the admin panel), providing a much shorter and more manageable list (like in the profile area, like XenForo, like phpBB, like Windows, like OS X, like Ubuntu) or we can revert to this unintuitive pile of crap that doesn't even work properly for countries that don't have hour-boundary places (like SMF)
-
I just checked and there's only Africa/Cairo, which is not visible if you remove the Africa region manually...?
They're usually in 'Other', which is removed manually, right...?
Yes, but Windows (I only know of Windows) guesses my timezone automatically -- probably because of my language more than anything... French => France => Only one timezone? We're good to go. Heck, maybe it could be implemented as well here... i.e. take the 'big' countries that have only one timezone, and try to set them by default according to the language... (and/or with regards to the timezone evaluated through time offsets.)
...Or have a large list that is only loaded through Ajax and, while we're at it -- selects the 'most likely' timezone as default...
-
- admin area. That's where you forgot Africa ;)
- we don't ask for language but we have the browser's default language at that point... Including regional languages :) eg Quebec.
- then selective Ajax maybe? Ie select continent then we load their timezone list via Ajax. Although it makes it hard to at a default zone with the browser language.
-
Ugh, that's the last time I rely on code posted on php.net :/
We have the browser's default language, yes. It's a starting point, perhaps, but I'd argue it's even more insane and effort intensive than using the list I already did, seeing how there's many different language codes, that's a couple of hundred in memory serves, and I *really* don't want to go through the codes to figure out what timezones might be applicable.
That also assumes that the timezone is right. What happens if, say, I take my laptop (which is set to en_GB) to America? All of a sudden it's now very wrong ;) That's an extreme and unlikely case but it's why you can't truly risk selective AJAX. But I wouldn't be opposed to two dropdowns, the second populated by the first (e.g. continent => region)
Mind you, what's actually so wrong with a single dropdown? I can put in a nice graphical map if that would help?
-
Ugh, that's the last time I rely on code posted on php.net :/
We have the browser's default language, yes. It's a starting point, perhaps, but I'd argue it's even more insane and effort intensive than using the list I already did, seeing how there's many different language codes, that's a couple of hundred in memory serves, and I *really* don't want to go through the codes to figure out what timezones might be applicable.
new Date().getTimezoneOffset() would get our timezone, and we'd just need to select the first entry in the select box that matches the timezone... (Only if no timezone is already selected, of course.)Mind you, what's actually so wrong with a single dropdown? I can put in a nice graphical map if that would help?
Then again, I registered on a phpBB website today, and it had a timezone list, and oh hell, the actual option values are *timezone offsets*... Which is not exactly great for daylight savings ;)
-
Then at least getting the timezone approximately right would be better than nothing I suppose...?
Then again, I registered on a phpBB website today, and it had a timezone list, and oh hell, the actual option values are *timezone offsets*... Which is not exactly great for daylight savings
-
If 'getting it approximately right' is acceptable, why bother with timezones anywhere and simply just use time offset?
(I could just ignore the server time, force it set to UTC, not have a server time offset and just simply have everyone set their own time offset from that, but that would be unpleasant)
Oh, I didn't look at the actual options in a phpBB website registration, but the presentation is still very much the same thing. (And DST is why time offset is fundamentally broken.)
-
But that's how SMF does it, isn't it...?
If the user timezone is set properly, you don't really have to have the server's time offset (though we *can* for the purposes of guest timezones, I guess), you just have to really worry about server + user timezone and everything else will pretty much just work.
Really what we're arguing about is how idiot proof we make it for the user, not the underlying code which is mostly working (it's ALL UI issues related to timezone, nothing else)
-
Wouldn't it be simpler to just set the server/mysql time to UTC..?
One thing that bothers me -- I know it's not much but still: let's say you post at 7pm on a Saturday, after a Doctor Who episode. The next day, daylight savings come into play and suddenly if you read that post, it's marked as being sent at 6pm... Before the episode was shown!! What the hell?!
I'd like for timezones to be able to automatically apply the timezone's daylight savings to a unix timestamp immediately... Dunno if they do that, honestly :P
-
Wouldn't it be simpler to just set the server/mysql time to UTC..?
I'd like for timezones to be able to automatically apply the timezone's daylight savings to a unix timestamp immediately... Dunno if they do that, honestly
-
No, because the system's clock will update with its local timezone rules, so you have to get that right, otherwise you'll get DST applying at times you have no knowledge of whatsoever.
They don't. You certainly could do it yourself, if you knew the timezone the post was written in, but that means storing it per post and doing extra calculations to do it. But for the extra hassle, it seems... overkill.
-
But the server uses unix timestamps, doesn't it..? Isn't this a UTC timestamp?
-
Oh, bugger... I thought I'd read that it was UTC.
-
Only if the server is UTC. It just returns the system time, really.
-
OK, so I fixed the UI bug and added it to the registration page. It isn't pretty, but it's still better than what we have now.
-
Can this be moved?
-
I still have a *little* more to do with it but it's mostly done.
-
Hmm, I can't remember what else I need to do with this >_>
-
Me neither...
Kinda went to other things because we couldn't agree on stuff here, IIRC... I've kept somewhere a copy of the timezones as shown by vBulletin and phpBB, both having their pros and cons. Still dunno what's best.
-
The timezones shown by others are pretty much the same list ;)
-
Not entirely, but very close.
In vB:
- Caracaz is in its own (new?) timezone (-4.5)
- some cities are in the list that aren't in the other (and vice versa), overall the vB version is more targeted towards populated areas
- Indian cities use their 'modern' names (Mumbai instead of Bombay, Kolkata instead of Calcutta... Which sounds odd to me because in France we never 'cared' to follow the renaming)
- it supports Kathmandu (with its very amusing 5.75 offset)
- also adds a Yangon (Rangoon IIRC) timezone
- uses "Beijing" instead of "Taipei" in the 8.0 timezone (dunno about you, but it feels like they tried very hard to please the DRC government...)
- and adds some Russian places that aren't mentioned in phpBB such as Vladivostok and Kamchatka -- yeah, once again it looks like vB tried to please communist governments, eh eh.
Overall I'd say that the phpBB version is outdated since it's missing at least 3 timezones (-4.5, 5.75 and 6.5). It nearly looks like they took the phpBB version and simply updated it over time (maybe the phpBB version I found was from an old install, but it didn't seem like it, it had a modern skin).
Of course, it's not like they *can't* copy the phpBB version, after all we're all in the same world, using the same timezone system...
-
It would really help if we knew people in these areas to be able to judge what's right.
It's no big deal to add these extra items in, though ;)
-
It would really help if we knew people in these areas to be able to judge what's right.
It's no big deal to add these extra items in, though ;)
As far as Russia is concerned, there are two "standard" times used throughout the country. There's the "longitudinal" time with St Petersburg and Moscow at GMT+4 through to Vladivostok at GMT+10, by which businesses operate at the local level; there's also "Moscow Time" which is still used by the railways and (I believe) airlines and is also used by businesses, government departments etc., at the national level. China follows a similar model.
That said though, I recently installed Ubuntu 12.04LTS onto a netbook that had previously been struggling with Windows 7 and I was pleasantly surprised to see that Ubuntu's installer was very obviously using geo-location to suggest the time-zone. You see, no software that I've come across ever suggests "Manila" and although it got the city wrong, it did get the right country. I'm wondering whether Wedge could use a similar system - just think of all those bytes you could save, Nao, by not having an extensive list of options! :)
-
and being British, I positively refuse to call it "UTC"
and I was pleasantly surprised to see that Ubuntu's installer was very obviously using geo-location to suggest the time-zone.
What did you put in as your language?just think of all those bytes you could save, Nao, by not having an extensive list of options! :)
1. Geolocation is a rat's nest, and that's going to get worse, not better, as IPv4 exhaustion will lead to buying and selling blocks.
2. We don't have the resources to generate the relevant lists, and I don't see us paying for the maintained lists - and that's a good way to push upgrading.
3. I'm fairly certain there are privacy implications.
4. The alternative is to use the Location API but not all browsers support is and of those that do, they all ask first for permission to use the API. Fairly certain most users would say no.
5. Other than IP address, the only other measure is the language code, which may or may not be accurate and it won't tell you the location of the user in all cases.
-
Not really adding a great deal to the debate, but I keep all my *nix servers locked at UTC, no matter where they are physically (or virtually) in the world (barring the server at work that handles our Subversion repos, otherwise the devs get all upset when the DST switchovers occur and SVN refuses their commits :eheh:); logs are easy enough to understand in UTC, and everything else DST is pretty much handled transparently on the client-side IMO (email datetime strings, f'rinstance).
As well you should, GMT != UTC anyway. The two are different notably that UTC is UTC is UTC and never varies, even for DST while GMT is only the placeholder assigned to Britain etc. during the winter months. There are some minor vagaries involved at the system level too but nothing to worry about.
Yes, and no. While the time prime meridian is acknowledged to run through Greenwich (and long may that remain the case; anyone want to come to GRO with me to look at the Harrison timepieces?), there is no difference between GMT and UTC (and insofar as "lies told to children", can be treated as being exactly the same thing). Should the EU bigwigs decide to move the time prime meridian (to *spit* Paris, f'rinstance), then this would necessarily introduce a 1hr difference between GMT and UTC.
-
I has a sad :(
Everything's configured right, yet when DST ended here 10 minutes ago it didn't automatically pick it up :( I have no idea why!
Posted: October 28th, 2012, 02:12 AM
Nao: is the server in Paris? If it is not in Paris, update the server timezone to where it actually is please.
Posted: October 28th, 2012, 02:14 AM
Scratch that, don't change it. I just have no idea how to fix this right now. Bah.
-
Now I'm *REALLY* confused. The settings are all exactly as they were 12 hours ago but now it's working properly.
-
OK, there is a bug with this under certain circumstances where it chooses to use the wrong timezone settings in thread view - but it's hard to spot, let alone debug. Going to investigate.
-
I think I've nailed this down now. I'll commit it next time I do a commit.