Fix RFC 3339 date handling #34
Conversation
Glossy was mixing a time offset with UTC dates when producing syslog messages. This change fixes this so that time offsets are used properly. Original discussion around this can be found here: squeeks#33
Conflicts: lib/glossy/produce.js
|
@squeeks how does this look to you? |
|
I'd like to see this merged so I can stop depending on a git repo fork. For some reason this branch seems to produce significantly greater variance in my test suite. The difference between the date extracted from the message and a new date object is consistently 200-700ms, where before I gave it a range of 0-10 ms. A brief test of just producing messages seems to go the other way, however: straight up calls to .produce were much faster with this branch. Not sure what it's all about and I haven't had to wrap my head around this code for months, just thought it was worth mentioning. Edit: maybe it's to do with parsing differences between the Z format and a timestamped format. Still seems like a HUGE difference. |
|
Ahh. The obvious answer: timestamps produced this way do not include milliseconds. And that's the answer to my old question of "Why |
|
@squeeks could you merge this? |
Glossy was mixing a time offset with UTC dates when producing syslog messages. This change fixes this so that time offsets are used properly. Original discussion around this can be found here: squeeks#33
Glossy was mixing a time offset with UTC dates when producing syslog messages. This change fixes this so that time offsets are used properly.
Original discussion around this can be found here: #33