Agreed. Is there any reason we can't just set the internal clock on the machine to UTC? (I personally can't, as I don't have root access to the server.)
I suppose we might want to automagically add 7 (or 8?) hours to the timezone settings of anyone who's set it, of course, so they still end up correct.
Yes, whether we fix it by changing the server time itself, or by fixing the software to use UTC instead of server time, the user table in the database will have to be updated.
Changing the time on the server is a decision Jimbo/Jason will have to make, because it may have effects with other machines on their network. I really should fix the software; it's just that I haven't personally felt that it was an important thing to spend time on, but I suppose there are enough complaints now to raise that priority.
lcrocker@nupedia.com wrote:
Changing the time on the server is a decision Jimbo/Jason will have to make, because it may have effects with other machines on their network.
I have no objection to setting the machine to UTC.
Part of the point of the new server is that I'm trying to sort out Wikipedia and Nupedia from everything else here.
--Jimbo
At 2002-08-21 13:05 -0700, lcrocker@nupedia.com wrote:
Agreed. Is there any reason we can't just set the internal clock on the machine to UTC? (I personally can't, as I don't have root access to the server.)
I suppose we might want to automagically add 7 (or 8?) hours to the timezone settings of anyone who's set it, of course, so they still end up correct.
Yes, whether we fix it by changing the server time itself, or by fixing the software to use UTC instead of server time, the user table in the database will have to be updated.
If updating the database is a problem, a more smoother conversion might be to add a flag to signify who is still using the old system and who is using the new system. Everyone using the old system would be converted whenever he changes his settings.
I don't know if this system would be less complex than changing the complete user database at once.
Changing the time on the server is a decision Jimbo/Jason will have to make, because it may have effects with other machines on their network.
I wouldn't do that if the server is really in that timezone. Servers have an actual location on earth and should run in local time, I think.
I really should fix the software; it's just that I haven't personally felt that it was an important thing to spend time on, but I suppose there are enough complaints now to raise that priority.
It looks very silly and a lot of people come across it...
Greetings, Jaap
On Wednesday 21 August 2002 16:53, Jaap van Ganswijk wrote:
I wouldn't do that if the server is really in that timezone. Servers have an actual location on earth and should run in local time, I think.
Servers serve the whole world and should run in UTC. What the time zone at the server's physical location is is irrelevant. Time zone change is disruptive, and though it happens at 2:00 in local time, that is broad daylight elsewhere on the globe.
I have no trouble remembering that my time zone is 4 hours west of Greenwich in the summer and 5 in the winter. But if I were trying to make sense of logs kept in Australian time, which shifts forward when I shift back and maybe a few weeks off, I would get quite confused.
phma
Pierre Abbat wrote:
On Wednesday 21 August 2002 16:53, Jaap van Ganswijk wrote:
I wouldn't do that if the server is really in that timezone. Servers have an actual location on earth and should run in local time, I think.
Servers serve the whole world and should run in UTC. What the time zone at the server's physical location is is irrelevant. Time zone change is disruptive, and though it happens at 2:00 in local time, that is broad daylight elsewhere on the globe.
Plus, end users can set the TZ environment variable so that they can type 'date' and get a happy answer, local to them.
--Jimbo
On Wed, 21 Aug 2002, Pierre Abbat wrote:
I have no trouble remembering that my time zone is 4 hours west of Greenwich in the summer and 5 in the winter. But if I were trying to make sense of logs kept in Australian time, which shifts forward when I shift back and maybe a few weeks off, I would get quite confused.
Not to mention Afghanistan, where they're x and a half hour off. :)
-- Daniel
At 2002-08-21 18:34 -0400, Pierre Abbat wrote:
On Wednesday 21 August 2002 16:53, Jaap van Ganswijk wrote:
I wouldn't do that if the server is really in that timezone. Servers have an actual location on earth and should run in local time, I think.
Servers serve the whole world and should run in UTC.
Of course I agree with you that in a perfect world there should only be one time. What does it matter at what time Australians get up, they will get used to it. They celebrate christmas in summer, why not get up at 00:00 and go to bed at 16:00? (I often do, although I'm in the Netherlands). Of course I'm also dead set against daylight savings time and think that the responsible politicians should be shot. I used to work as an embedded programmer and most people have no idea how difficult issues of time and date can be, even without daylight savings time. We used to make machines for the justice department over here, and the best advice I can give any crook: Do your evil deeds between 2:00 and 3:00 in the night the clock is being set back and make the lawyers ask for a mistrial because the exact time of the crime has not been reported correctly.
What the time zone at the server's physical location is is irrelevant.
On the other hand I'm very practical and say: Use the local time, but follow common Unix practice. This problem is not new. Unix systems keep track of local time and universal time and it's not too hard to get any kind of time out of a Unix system.
The MS-DOS system was much funnier: A file second's time couldn't be odd. Bill Gates tried to compress the date and time in a kind of BCD in 32 bits and he came one bit short...
Time zone change is disruptive, and though it happens at 2:00 in local time, that is broad daylight elsewhere on the globe.
What are you saying? Are you unaware that Unix systems count the time in seconds since 1970 and derive all other further knowledge of date and time from that?
(Of course then the next question is: does the system keep time in seconds since 1970-01-01 UTC or any other local time...?)
I have no trouble remembering that my time zone is 4 hours west of Greenwich in the summer and 5 in the winter.
Yes, but I always wonder: Isn't the daylight saving time valid in Greenwich itself?
So is our time relative to a virtual time that the Greenwichers themselves live at, or at the time that they really have on their watches?
I think that politicians that mess with time are messing with the essence of things you can't mess with and should be shot.
But if I were trying to make sense of logs kept in Australian time, which shifts forward when I shift back and maybe a few weeks off, I would get quite confused.
Indeed. We should have a single universal time and date accross the whole globe. We should also spell it in the same way: 20020822 01:38 or 2002-08-22 01:38
It's strange however that years are counted from the birth of a jewish rebel called Christ in 0000 (or 0001 as some claim), months also from 01, days also from 01, but hours and minutes from 00, although the angloamericans tend to count minutes beyond the 12/24. The use of AM/PM is extra confusing, because the question (for non angloamericans is) is 12:30 AM or PM?
I'm not advocating the Swass Beat system which divides each day into 1000 beats and which are the same over the whole world, but especially you anglo-americans should wise up!
Greetz, Jaap
wikipedia-l@lists.wikimedia.org