Display local DHCP lease times in 24-hour clock
-
This is a UI consistency thing, so debatable if it counts as a bugfix that could go into RELENG_2_3_2:
https://github.com/pfsense/pfsense/commit/4e5477eace9aa5f00c53ff62ca3e35e38177bb09 -
I agree: the timestamps should be consistently rendered, and I do find the 24hr format easier to quickly skim through.
Also, I always enable the "Change DHCP display lease time from UTC to local time" option. Can someone explain to me a "use case" for NOT doing this? It seems so much more natural to me.
-
I agree: the timestamps should be consistently rendered, and I do find the 24hr format easier to quickly skim through.
Also, I always enable the "Change DHCP display lease time from UTC to local time" option. Can someone explain to me a "use case" for NOT doing this? It seems so much more natural to me.
I also prefer local time. The only reason I can think of for using UTC is if the system is being used on a network that spans multiple time zones.
-
Or if managed from a different time zone than it resides in, perhaps it could be useful.
That didn't come out quite right. Let me try again.
Maybe if managing numerous systems in many different time zones it could be useful to have them all displaying UTC instead of each displaying their local time.
-
Also, I always enable the "Change DHCP display lease time from UTC to local time" option. Can someone explain to me a "use case" for NOT doing this? It seems so much more natural to me.
It may be natural to people living in that timezone. Now, look at this: 2.3.3-DEVELOPMENT (amd64) built on Mon Sep 26 09:29:52 CDT 2016. I have no idea what the heck CDT is. I also hate AM/PM, oh and please don't get me started about the MM/DD/YY date format - like 01/02/03 - oh great… >:() Could someone switch the darned builder to UTC? Might finally be able to figure out whether a bugfix commit had a chance to get included or not quickly.
-
Yes, I wish that every server that does stuff for an inter[state|national] audience was set to UTC. Then every forum post, commit, build, log entry… would be shown in the UTC time that it happened and there would be no ambiguity and easy comparison of times.
And every date should be shown in YYYY/MM/DD format that is easy to compare and sorts beautifully.
-
The benefit of UTC for the DHCP leases is that it's the natural time zone used by the DHCP daemon internally. Showing the times in UTC means showing them unaltered from the leases file, adjusting the times means (in a roundabout way) that you're not seeing the data from the leases as-is. Not to say adjusting it's a bad thing, it's quite useful, but if you are troubleshooting an issue with leases it can be helpful to see the exact time from the file rather than an adjusted version. You can always peek at /var/dhcpd/var/db/dhcpd.leases if you need to see that deep, though.
As for the builder, the office (in Austin, TX) is on US Central Daylight Time (CDT) right now, will be CST when daylight saving time ends. We prefer to compare times in the local time zone since even our international employees operate on office time, but there is a strong case to be made for UTC everywhere when it comes to such things. Changing the TZ on the builders would be all that's needed there if we choose to go that way.
The format of the output "Mon Sep 26 09:29:52 CDT 2016" is set in the builder code, though any place that compares it (like the version comparison code) would have to be smart enough to compare different formats if we change it. Existing installs might get confused if they are checking the date.
It's only set in one place:
tools/builder_defaults.sh: export BUILTDATESTRING=$(date "+%a %b %d %T %Z %Y")The filename and a couple other places use this instead:
tools/builder_defaults.sh: export DATESTRING=$(date "+%Y%m%d-%H%M")I also much prefer YYYY-MM-DD, primarily due to how well it sorts, though changing either format at this point may be a bit more work than it appears on the surface.
-
I was just making a general statement about "philosophy of date time", not really suggesting some change to the way pfSense builds work. Although it would be nice if the forum ran on UTC, then everyone can easily put a time offset into their profile that is simply the offset from UTC of their own timezone, which they are familiar with. And then the forum time does not move when there is summer time for CST.
-
Normalizing date formats is a very laudable idea. But please stay with ISO 8601 formats. No slashes.
2016-09-30
