IETF
sedate
sedate@jabber.ietf.org
Monday, July 25, 2022< ^ >
Meetecho has set the subject to: https://notes.ietf.org/notes-ietf-113-sedate
Room Configuration
Room Occupants

GMT+0
[05:34:02] zulipbot joins the room
[14:00:26] cabo joins the room
[17:16:58] <zulipbot> (Bron Gondwana) thank you for starting us up :)
[17:31:33] <zulipbot> (Ujjwal Sharma) hey folks
[17:31:48] <zulipbot> (Ujjwal Sharma) question: is the matrix bridge still operational for this meeting?
[17:32:01] <zulipbot> (Robert Stepanek) yes
[17:32:01] <zulipbot> (Carsten Bormann) Zulip is the flavor of the week
[17:32:27] <zulipbot> (Robert Stepanek) it is. can't see you own video, though (maybe that's just me)
[17:32:40] <zulipbot> (Robert Stepanek) s/own/on/
[17:32:56] <zulipbot> (Ujjwal Sharma) oh, I like matrix better :(
[17:33:22] <zulipbot> (Bron Gondwana) Robert: mostly you aren't streaming video unless you explicitly ask to
[17:33:22] <zulipbot> (Robert Stepanek) gotcha
[17:34:18] <zulipbot> (Ujjwal Sharma) wait, does that mean that XMPP isn't active either?
[17:34:23] <cabo> It is
[17:34:27] <cabo> For the last time
[17:34:31] <zulipbot> (Bron Gondwana) I think it's ALL bridged this time
[17:34:34] ryzokuken joins the room
[17:35:14] <ryzokuken> ah nice, hello from XMPP
[17:39:17] <zulipbot> (Ujjwal Sharma) Common Locale Data Repository
[17:56:49] <zulipbot> (Carsten Bormann) 4.3. Unknown Local Offset Convention
   If the time in UTC is known, but the offset to local time is unknown,
   this can be represented with an offset of "-00:00".  This differs
   semantically from an offset of "Z" or "+00:00", which imply that UTC
   is the preferred reference point for the specified time.  RFC2822
   [IMAIL-UPDATE] describes a similar convention for email.
[17:58:11] <zulipbot> (Ujjwal Sharma) @Bron: as perhaps the most experienced implementer in the room, do you have any comments?
[18:08:12] <zulipbot> (Bron Gondwana) I want some examples
[18:09:09] <zulipbot> (Bron Gondwana) just to be 100% sure that I know what this means... certainly 'Z' means offsets may have been applied to make this time align to UTC
[18:09:35] <zulipbot> (Bron Gondwana) but it doesn't mean that "I assert this time is associated with the GMT timezone"
[18:14:13] <zulipbot> (Carsten Bormann) 18:00Z[America/New York] is not a conflict, and is equivalent to 14:00-04:00[America/New York]
[18:16:21] <zulipbot> (Carsten Bormann) Z no longer does "imply that UTC
is the preferred reference point for the specified time.".
[18:17:29] <zulipbot> (Bron Gondwana) great, that's what I was checking that everyone agrees with!
[18:17:45] <zulipbot> (Bron Gondwana) you can always convert to UTC but still give the zone name
[18:22:58] <zulipbot> (Justin Grant) I agree with Bron's comment in chat and his later one live just now.
[18:29:20] <zulipbot> (Ujjwal Sharma) had been under the impression that this would be fixed once we get the liason relationship...
[18:31:01] <zulipbot> (Carsten Bormann) We have more fruitful relationships with IEEE
[18:31:14] <zulipbot> (Carsten Bormann) But ISO really is a hard nut
[18:31:40] <zulipbot> (Justin Grant) Thanks everyone!
[18:31:40] <zulipbot> (Ujjwal Sharma) Thanks!
[18:37:11] ryzokuken leaves the room
[20:23:12] cabo leaves the room