From: Hanna L. <ha...@us...> - 2003-04-22 17:42:08
|
In light of our speaker sleeping through the meeting and the fact that kernel hackers tend not to be awake early in the morning I propose moving the time of the call to 1pm Pacific Time (GMT-0800). Originally we chose 9:30am to encourage people in Europe and India to attend. However, the time change has not increased attendance so I think we should move it to a more reasonable time for North American Continental dwellers who are the main attendees. Any comments? Debate? Hate mail? Send to me or lse...@li... Hanna --On Friday, April 18, 2003 03:08:10 PM -0700 William Lee Irwin III <wl...@ho...> wrote: > At some point in the past, John Bradford wrote: >>> Nobody else is in the conference, has it been cancelled, or am I late? :-) > > On Fri, Apr 18, 2003 at 12:58:42PM -0700, Cliff White wrote: >> You were a bit late. Mr. Irwin didn't show, so it was a very brief call. >> cliffw > > Sorry about that, I fell asleep shortly before the call despite > attempts not to. > > > -- wli > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to maj...@vg... > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > |
From: Bill D. <dav...@tm...> - 2003-04-25 18:03:12
|
On Tue, 22 Apr 2003, Hanna Linder wrote: > > In light of our speaker sleeping through the meeting and > the fact that kernel hackers tend not to be awake early > in the morning I propose moving the time of the call to > 1pm Pacific Time (GMT-0800). > > Originally we chose 9:30am to encourage people in Europe and > India to attend. However, the time change has not increased > attendance so I think we should move it to a more reasonable > time for North American Continental dwellers who are the > main attendees. > > Any comments? Debate? Hate mail? Must have been really short, I missed it coming in a tad late. In any case, NY is nicely in the middle between CA and Europe, so any time good on the ends will be fine here. On Tue, 22 Apr 2003, jw schultz wrote: > On Tue, Apr 22, 2003 at 06:49:41PM +0100, John Bradford wrote: > > > In light of our speaker sleeping through the meeting and > > > the fact that kernel hackers tend not to be awake early > > > in the morning I propose moving the time of the call to > > > 1pm Pacific Time (GMT-0800). > > > > 10 PM U.K. time is no problem for me. > > I think Hanna meant 1:00PM PDT (GMT-0700) With UK on DST it > is still 8 hours difference. I think that also puts it > around 6-8AM down under. Please just give time in GMT and let us work it out! Between time zones and daylight savings it's more confusing than useful. Last week I went to Arizona from New York. It went like this: Sunday morning 1hr forward for DST. Sunday later, 2hr back for central timezone. Sunday later 1hr more back, Arizona doesn't do DST, except... Monday, 1hr forward again, the Navaho nation in AZ does do DST. At that point I set my watch to GMT and told local time by the sun! Oh well, lots of brewpubs, it's always time for a beer. -- bill davidsen <dav...@tm...> CTO, TMR Associates, Inc Doing interesting things with little computers since 1979. |
From: John B. <jo...@gr...> - 2003-04-25 18:23:05
|
> Last week I went to Arizona from New York. It went like this: Sunday > morning 1hr forward for DST. Sunday later, 2hr back for central timezone. > Sunday later 1hr more back, Arizona doesn't do DST, except... Monday, 1hr > forward again, the Navaho nation in AZ does do DST. At that point I set my > watch to GMT and told local time by the sun! Oh well, lots of brewpubs, > it's always time for a beer. Ah, but assuming that you had a compass to calculate the local time offset, (ignoring DST), anyway, you could have used that to calculate the _local_ time without looking at your watch at all ;-). However, you wouldn't be able to calculate the timezone you were in. John. |
From: Scott R. L. <co...@co...> - 2003-05-02 15:34:40
|
John Bradford wrote: > Ah, but assuming that you had a compass to calculate the local time > offset, (ignoring DST), anyway, you could have used that to calculate > the _local_ time without looking at your watch at all ;-). However, > you wouldn't be able to calculate the timezone you were in. Ah, but if you had a GPS system available, and a database of time zone boundaries, you could adjust on-the-fly for different jurisdictions. I've dones somethign of the sort recently for a client; the main problem lies in the accuracy (and size) of the database. Indiana, for example, presents unique challenges, with its patchwork implementation of DST... -- Scott Robert Ladd Coyote Gulch Productions (http://www.coyotegulch.com) |
From: John B. <jo...@gr...> - 2003-05-02 15:47:33
|
> > Ah, but assuming that you had a compass to calculate the local time > > offset, (ignoring DST), anyway, you could have used that to calculate > > the _local_ time without looking at your watch at all ;-). However, > > you wouldn't be able to calculate the timezone you were in. > > Ah, but if you had a GPS system available, and a database of time zone > boundaries, you could adjust on-the-fly for different jurisdictions. > I've dones somethign of the sort recently for a client; the main problem > lies in the accuracy (and size) of the database. Indiana, for example, > presents unique challenges, with its patchwork implementation of DST... Hanna, can we add this to the list of things to discuss in the LSE conference call, please? John. |
From: Hanna L. <ha...@us...> - 2003-05-02 16:23:05
|
--On Friday, May 02, 2003 04:51:11 PM +0100 John Bradford <jo...@gr...> wrote: >> > Ah, but assuming that you had a compass to calculate the local time >> > offset, (ignoring DST), anyway, you could have used that to calculate >> > the _local_ time without looking at your watch at all ;-). However, >> > you wouldn't be able to calculate the timezone you were in. >> >> Ah, but if you had a GPS system available, and a database of time zone >> boundaries, you could adjust on-the-fly for different jurisdictions. >> I've dones somethign of the sort recently for a client; the main problem >> lies in the accuracy (and size) of the database. Indiana, for example, >> presents unique challenges, with its patchwork implementation of DST... > > Hanna, can we add this to the list of things to discuss in the LSE conference call, please? > > John. Seriously? A database of timezones? I think UTC is fine, I just need to remember to change it for Daylight Savings Time sometimes. But we can discuss it if there is time. Hanna |
From: Scott R. L. <co...@co...> - 2003-05-02 16:57:20
|
Hanna Linder wrote: > Seriously? A database of timezones? I think UTC is fine, I just need to > remember to change it for Daylight Savings Time sometimes. But we can > discuss it if there is time. Time zone databases are publicly available, some under the GPL, even; they're commonly used in GIS and geospatial applications. While they're too big to store in a small device, I've used network links to cross-reference GPS-acquired location data with time zone data. -- Scott Robert Ladd Coyote Gulch Productions (http://www.coyotegulch.com) |
From: John B. <jo...@gr...> - 2003-05-02 17:14:48
|
> > Seriously? A database of timezones? I think UTC is fine, I just need to > > remember to change it for Daylight Savings Time sometimes. But we can > > discuss it if there is time. > > Time zone databases are publicly available, some under the GPL, even; > they're commonly used in GIS and geospatial applications. While they're > too big to store in a small device, I've used network links to > cross-reference GPS-acquired location data with time zone data. It was a _joke_! I've just said that in the conference! John. |
From: Scott R. L. <co...@co...> - 2003-05-02 17:39:44
|
John Bradford wrote: > It was a _joke_! I've just said that in the conference! Ah, such is life. I'm very good at providing answers in search of a question. :) ..Scott |
From: <ebi...@xm...> - 2003-05-03 14:20:45
|
Scott Robert Ladd <co...@co...> writes: > John Bradford wrote: > > Ah, but assuming that you had a compass to calculate the local time > > offset, (ignoring DST), anyway, you could have used that to calculate > > the _local_ time without looking at your watch at all ;-). However, > > you wouldn't be able to calculate the timezone you were in. > > Ah, but if you had a GPS system available, and a database of time zone > boundaries, you could adjust on-the-fly for different jurisdictions. I've dones > somethign of the sort recently for a client; the main problem lies in the > accuracy (and size) of the database. Indiana, for example, presents unique > challenges, with its patchwork implementation of DST... Indiana doesn't do DST. But it is true that people on the edges of the state like to know what time it is for their neighbors across the border. I suspect the border case is at least slightly true for other places right on the border between timezones, as well. Though I can't think of any other examples right now. Eric |
From: John B. <jo...@gr...> - 2003-04-22 17:47:18
|
> In light of our speaker sleeping through the meeting and > the fact that kernel hackers tend not to be awake early > in the morning I propose moving the time of the call to > 1pm Pacific Time (GMT-0800). 10 PM U.K. time is no problem for me. > Originally we chose 9:30am to encourage people in Europe and > India to attend. However, the time change has not increased > attendance so I think we should move it to a more reasonable > time for North American Continental dwellers who are the > main attendees. > > Any comments? Debate? Hate mail? Flame war? :-) John. |