--- job@ntt.net wrote: From: Job Snijders <job@ntt.net> on this topic, i strongly recommend to operate all devices in the Etc/UTC timezone, this makes coordination with external entities much easier. ---------------------------------------- Yes, this! Holy crap I come upon a lot of networks that don't do this and it's always painful. scott
On 5/8/19 4:00 PM, Scott Weeks wrote:
--- job@ntt.net wrote: From: Job Snijders <job@ntt.net>
on this topic, i strongly recommend to operate all devices in the Etc/UTC timezone, this makes coordination with external entities much easier. ----------------------------------------
Yes, this! Holy crap I come upon a lot of networks that don't do this and it's always painful.
scott
Now if only we could get rid of Daylight Saving Time ...
On Wed, 08 May 2019 14:00:11 -0700, "Scott Weeks" said:
From: Job Snijders <job@ntt.net>
on this topic, i strongly recommend to operate all devices in the Etc/UTC timezone, this makes coordination with external entities much easier. ----------------------------------------
Yes, this! Holy crap I come upon a lot of networks that don't do this and it's always painful.
Newfoundland time, anybody? :)
On Wed, May 8, 2019 at 9:42 PM Valdis Klētnieks <valdis.kletnieks@vt.edu> wrote:
Newfoundland time, anybody? :)
isn't the point: "Pick one for all of your things, stick to that one thing" it's find if you pick central indiana time, if you are setting the same everywhere and keeping it update properly...AND you agree that when I send you central Fiji time you'll silently convert =57 hrs and understand that we're talking about the same slice of time. UTC is nice EST is nice PDT is nice.. pick one, deal with the eccentricities of that decision without foisting your religion on the rest of me. :) Also, PLEASE use a constant / automatic time source that's available world-wide (like NTP). -chris
isn't the point: "Pick one for all of your things, stick to that one thing" it's find if you pick central indiana time, if you are setting the same everywhere and keeping it update properly
i find the time zone they choose says a lot about an operation. can be a flag of parochialism. randy
Hello, On Wed, May 08, 2019 at 10:27:30PM -0400, Christopher Morrow wrote:
UTC is nice EST is nice PDT is nice..
pick one, deal with the eccentricities of that decision without foisting your religion on the rest of me. :)
Yes and no. Anything non-UTC can cause issues when working with other organisations. More than once I've received logs or incident notifications from suppliers without a time zone stated at all. I've then asked the time zone only to be told "It's PST" when in fact the real answer was PDT as the supplier was currently in DST. Others shouldn't have to work this hard, epseically with DST dates being a matter of local legislation, and one way of helping that to happen from the first line support up is to use UTC. Cheers, Andy
On Thu, May 9, 2019 at 3:12 PM Andy Smith <andy@strugglers.net> wrote:
Hello,
On Wed, May 08, 2019 at 10:27:30PM -0400, Christopher Morrow wrote:
UTC is nice EST is nice PDT is nice..
pick one, deal with the eccentricities of that decision without foisting your religion on the rest of me. :)
Yes and no. Anything non-UTC can cause issues when working with other organisations.
"deal with the eccentricities of that decision without foisting your religion on the rest of me" I clearly mistyped: "me" at the end there with "us"... Your point is squarely on: Hey, you do you... when you talk to me be prepared to normalize my TZ and yours. (which may mean;: send in UTC store in ElboniaStandardTime"
More than once I've received logs or incident notifications from suppliers without a time zone stated at all. I've then asked the time zone only to be told "It's PST" when in fact the real answer was PDT as the supplier was currently in DST. Others shouldn't have to work this hard, epseically with DST dates being a matter of local legislation, and one way of helping that to happen from the first line support up is to use UTC.
Cheers, Andy
Many systems have less than ideal separation of collection, storage, viewing, export, etc. timezones. I prefer to view in local time. I may wish to export in another. Storage in UTC to facilitate all of this makes sense. Normalizing input timezones would be nice. A boy can only dream... ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "Christopher Morrow" <morrowc.lists@gmail.com> To: "nanog list" <nanog@nanog.org> Sent: Thursday, May 9, 2019 2:16:59 PM Subject: Re: NTP for ASBRs? On Thu, May 9, 2019 at 3:12 PM Andy Smith <andy@strugglers.net> wrote:
Hello,
On Wed, May 08, 2019 at 10:27:30PM -0400, Christopher Morrow wrote:
UTC is nice EST is nice PDT is nice..
pick one, deal with the eccentricities of that decision without foisting your religion on the rest of me. :)
Yes and no. Anything non-UTC can cause issues when working with other organisations.
"deal with the eccentricities of that decision without foisting your religion on the rest of me" I clearly mistyped: "me" at the end there with "us"... Your point is squarely on: Hey, you do you... when you talk to me be prepared to normalize my TZ and yours. (which may mean;: send in UTC store in ElboniaStandardTime"
More than once I've received logs or incident notifications from suppliers without a time zone stated at all. I've then asked the time zone only to be told "It's PST" when in fact the real answer was PDT as the supplier was currently in DST. Others shouldn't have to work this hard, epseically with DST dates being a matter of local legislation, and one way of helping that to happen from the first line support up is to use UTC.
Cheers, Andy
On Thu, May 9, 2019 at 4:42 PM Mike Hammett <nanog@ics-il.net> wrote:
Many systems have less than ideal separation of collection, storage, viewing, export, etc. timezones. I prefer to view in local time. I may wish to export in another. Storage in UTC to facilitate all of this makes sense. Normalizing input timezones would be nice.
A boy can only dream...
----- Mike "Dreamer of Dreams" Hammett
There I fixed it for ya! :) (I agree, btw, that this sort of thing would be nice :) and some folk can implement that today even :) )
Intelligent Computing Solutions http://www.ics-il.com
Midwest-IX http://www.midwest-ix.com
________________________________ From: "Christopher Morrow" <morrowc.lists@gmail.com> To: "nanog list" <nanog@nanog.org> Sent: Thursday, May 9, 2019 2:16:59 PM Subject: Re: NTP for ASBRs?
On Thu, May 9, 2019 at 3:12 PM Andy Smith <andy@strugglers.net> wrote:
Hello,
On Wed, May 08, 2019 at 10:27:30PM -0400, Christopher Morrow wrote:
UTC is nice EST is nice PDT is nice..
pick one, deal with the eccentricities of that decision without foisting your religion on the rest of me. :)
Yes and no. Anything non-UTC can cause issues when working with other organisations.
"deal with the eccentricities of that decision without foisting your religion on the rest of me"
I clearly mistyped: "me" at the end there with "us"... Your point is squarely on: Hey, you do you... when you talk to me be prepared to normalize my TZ and yours. (which may mean;: send in UTC store in ElboniaStandardTime"
More than once I've received logs or incident notifications from suppliers without a time zone stated at all. I've then asked the time zone only to be told "It's PST" when in fact the real answer was PDT as the supplier was currently in DST. Others shouldn't have to work this hard, epseically with DST dates being a matter of local legislation, and one way of helping that to happen from the first line support up is to use UTC.
Cheers, Andy
participants (7)
-
Andy Smith -
Bryan Holloway -
Christopher Morrow -
Mike Hammett -
Randy Bush -
Scott Weeks -
Valdis Klētnieks