Seamonkey Print page date/time error (Linux)

[tbwdave]

Hi. I have Seamonkey 2.53.4, running on Antix 17.4, 32 bit linux.

It works well, except that the page footer Date/Time shows 12/13/69, and the time is arbitrary.
In Preferences - Calendar - Date Text Format window, the current date is shown properly.

I also have Firefox and Thunderbird on the system. Both of those seem to handle date and time properly.

Please provide a clue or two.

Thanks!

[ndebord]

Hi. I have Seamonkey 2.53.4, running on Antix 17.4, 32 bit linux.

It works well, except that the page footer Date/Time shows 12/13/69, and the time is arbitrary.
In Preferences - Calendar - Date Text Format window, the current date is shown properly.

I also have Firefox and Thunderbird on the system. Both of those seem to handle date and time properly.

Please provide a clue or two.

Thanks!

tbwdave

FWIW, SM 2.53.4 (32 bit) in Windows shows the proper date time stamp.

[WaltS48]

Hi. I have Seamonkey 2.53.4, running on Antix 17.4, 32 bit linux.

It works well, except that the page footer Date/Time shows 12/13/69, and the time is arbitrary.
In Preferences - Calendar - Date Text Format window, the current date is shown properly.

I also have Firefox and Thunderbird on the system. Both of those seem to handle date and time properly.

Please provide a clue or two.

Thanks!

Is the Timezone set to the closest city in your timezone in Preferences > Calendar?

What is your setting under the Date and Time Formatting setting in Preferences > Appearance?

[tbwdave]

Is the Timezone set to the closest city in your timezone in Preferences > Calendar?
Yes. And, as previously stated, the Date shows correctly in Calendar - Date Text Format window: "Long: Tuesday, October 6, 2020"

What is your setting under the Date and Time Formatting setting in Preferences > Appearance?
It was set to "Application Locale: English (United States)"
The other option is "Regional Locale: English (United States)"
I switched to the other option, and restarted SeaMonkey, with not change in the Print Date/Time line.
So, I switched it back.

In Print Preview - Options, I can change to another option for this footer position (eg., URL) and the change takes effect properly upon printing. However, when Date/Time is selected, the date is always 12/31/69 and the time is 1:50pm or later. The time, in the footer, seems to start around 1:50pm at each computer reboot. However, the computer date and time is correct. It seems that footer (and header) info is not connected to the Date/Time source, even though the browser knows the date and time. I first noticed this issue, yesterday, with SM 2.53.3, and upgraded to 2.53.4, with no change. However, several months ago, with an earlier SM version the date/time printed properly. Of course, there have been other system upgrades since then, so I can't tag this to a SM version.

[therube]

?

I recently Archived and many folders now have a blank 12/31/1969 email in them

(If something relating to Thunderbird doesn't pan out, there were a lot of hits on the Grateful Dead .)

[tbwdave]

therube,
Thanks for sharing the similar sounding error with Thunderbird email archive dates.

I can't see that it applies directly, but I followed a rabbit trail, and found that FireFox v.53 had a similar problem a couple of years back (see
https://bugzilla.mozilla.org/show_bug.cgi?id=1362817).

That thread seems to be a discussion between developers as they figured out the cause, which affects 32 bit systems only (which is also true of my present problem). I'm not bright enough to know whether the solution they found can be applied to my present SeaMonkey version, or if I must patiently wait for it to be fixed (hopefully) with the next update.

[tbwdave]

Considering what I found in the above post (concerning a similar problem with FireFox, awhile ago), perhaps this thread should have been posted under SeaMonkey bugs.

I would appreciate evaluation by a forum moderator...
Is this problem a bug affecting SeaMonkey 2.53.4 (32 bit systems only)?
(A friend, who uses MX-19 linux on both 32 bit and 64 bit systems, confirms the same issue, on his 32 bit system. It works properly on his 64 bit system.)

If so, will be addressed soon?

Thank you!

[Frank Lion]

Considering what I found in the above post (concerning a similar problem with FireFox, awhile ago), perhaps this thread should have been posted under SeaMonkey bugs.

The only tenuous connection is the 31st of December 1969 date, which is the day before the default UNIX date of 1/1/1970.

i.e. whenever anything with dates goes wildly wrong, the date often reverts to its UNIX date, but that doesn't mean any connection between SM, T/Bird or Firefox problems.

Yours is a 32 bit Linux problem.

[tbwdave]

Okay... I'll take your word for it.

Thanks!

[Frank Lion]

Okay... I'll take your word for it.

That just means that historically Linux and printers (drivers) often just don't get along, so you have to suspect them before anything else.

However https://bugzilla.mozilla.org/show_bug.cgi?id=1362817 really does look linked here, the only mystery being why if this was fixed in Firefox 53 that it might still be a bug in SM.

Reckon I'll get this thread moved to bugs

[DanRaisch]

Moving to SeaMonkey Bugs forum.

[frg]

Thought I backported every intl bug > 56 but seems I missed this one. Will be fixed in tomorrows WG9s build and SeaMonkey 2.53.5b1. Affects only x86 Linux builds it seems. Just tested Windows x86 and it is fine.

[breee]

hello tbwdave
the print_ values of: if &T is title then why is &PT of total?
try &P is page number and &L is total pages loaded.

32 bit gonna get some love. delightful.
dating is outdated; that is just ... not funny.
Thanks frg for tackling this folds of date format update methods. changing all the time. .. again not funny .. by ff version.

fix to overall timestamp will fix both the reported 32bit linux faults at

devtools.netmonitor.har.defaultFileName ;Archive %date
and
print.print_footer*, use of value ;&D

hope? a timely fix just in time for another timely fix?
32bit linux I find the date printing error problematic workaround. Glad i did not suffer the archive name problem.