User Details
- User Since
- May 14 2014, 3:42 PM (576 w, 5 d)
Sat, May 31
Approved by: philip (mentor)
Sat, May 24
Wed, May 21
Tue, May 20
Sat, May 10
Approved by: philip (mentor)
Fri, May 9
Approved by: philip (mentor)
Thu, May 8
Approved by: philip (mentor)
Tue, May 6
Mon, May 5
Sun, May 4
May 1 2025
Apr 28 2025
I haven't tested this but assuming we do indeed use only interface ioctls, this looks like it should work.
Apr 23 2025
Looks good to me. Thank you for addressing @bz's comments.
Apr 11 2025
Apr 10 2025
Apr 9 2025
Apr 8 2025
I don't know anyone who uses this option. I certainly don't test it. :-)
I don't mind additional documentation.
Apr 7 2025
Apr 6 2025
Apr 5 2025
Apr 4 2025
This looks good to me -- modulo @diizzy's comments.
Apr 2 2025
Apr 1 2025
Mar 31 2025
Thanks for the feedback. That was my reasoning for doing posix_only instead of the tzdata default posix_right.
Mar 30 2025
This builds the "main" format of the time zone database. That includes backward compatibility links but it doesn't include historical ("backzone") data. The "redo" bit controls how leapseconds are handled. We may want this to be posix_right. I'm not sure what other vendors do here.
Mar 29 2025
Thank you for doing this work! At a glance, this looks good enough to give a test-drive on the cluster.
Mar 26 2025
Mar 23 2025
Mar 20 2025
Mar 19 2025
...and remember to update the date stamps and type something in a REVISION... :)
This looks good to me. Go ahead and commit this.
Feb 24 2025
Jan 30 2025
Jan 27 2025
Jan 20 2025
Jan 17 2025
Dec 27 2024
Dec 18 2024
Dec 16 2024
This looks good to me, but please wait for the security team to discuss this before committing. I have no idea what (if any) downstream consumers we have and how this will affect them. We have not touched this schema since 2005.
Dec 9 2024
Looks good! Thank you for the test case. :-)