pfSense » pfSense Packages

You mean this? http://www.urbandictionary.com/define.php?term=UDT&defid=5416562

:-D

That or lunch-time zone (Douglas Adams)

Not sure where's this fixed? Cannot see any update to the package, and just to be sure I made a backup and the time displayed is 6 hours off.

It really is easy. If you find yourself outside of the unknown backup server timezone, the diplayed backup times are crap. How much crap they are depends on the offset from the unknown backup server timezone. Considering the backup list does not list a timezone, I have no idea what's the time displayed supposed to mean. ATM, the times are 6 hours off the local timezone (Central European Time).

Just to avoid more confusion: CET=GMT+1. (And CEST=GMT+2 -- that's the daylight saving TZ which was used until last Sunday there.)

These are the exact same backup; the Backup History shows correct local time, the ACB list shows unknown TZ junk. (Even the date won't match depending on when the configuration change is made.)

So the missing information here is that you are talking about a package. I didn't realize that until I asked another team member. I should have checked the bug category :)

I'll research the matter.

Uhm. No idea why this bug got assigned to me. Nothing I could fix here.

Jim P wrote:

fixed now

It's now 7 hours off, instead of 6 previously.

Guys, I have NFC what magic are you trying to do there, but may I suggest to use the Unix timestamps which can be converted locally to whatever is proper local TZ by the package?

I meant I fixed the assignment :-)

LOLz... Well, unless you have had a DST switch in past two weeks, your server seems to be some sort of time travel machine. :-D

Jim P wrote:

went a fairly standard datestamp output format, feel free to submit suggestions for a different post-conversion format if the chosen one isn't OK.

Nah, RFC2822 is perfectly fine. Confirmed working, thanks :)

OK fix pushed. I tested and re-tested on 2.0.x and 2.1 as well, worked OK everywhere. Changing the firewall time zone was reflected in the list as well.

Yeah, deleting works now as well. Probably should nuke the {$_REQUEST['rmver']} from the savemsg on line 196, since it shows something different now than what the user has confirmed, and I don't think it's worth fiddling with this to make those match.

Went ahead and fixed it up there, too. It wasn't difficult to accommodate, better off this way anyhow.

Applied in changeset commit:13fcabcbb24889a43afb3748bdda5e9905de1fe5.

Works. I guess all set now. :)