Blog timestamp feature is random & doesn't work in albums

[Marxsal]

If you try the blog date feature, the note is inserted more or less randomly. On mine, it was below several dates that it should have been above.

Also, since the blog feature doesn't get applied to Albums, it is of limited use if you want to use the albums to combine multiple folders.

• OS: Linux, manjaro
• Firefox
• docker-edge (alpine)

[stenrock]

Did you set the sort order to date ascending and group by date?

[Marxsal]

Here's my comment file:

<!-- @pg-date 1960-05-15 -->

A day on the lawn. Probably a Sunday in the backyard.

<!-- @pg-date 1960-08-17 -->

### August

Here's the result. There are photos from May and August 19960 in the set. But the August label gets sorted to the top. I've tried variations, including putting each label with it's own comment file (in which case it gets ignored altogether).

[stenrock]

The images must have a correct timestamp. As it is images from the 1960:s I assume they are scanned to digital image files. Did you set the timestamp to the date they refer to?

[Marxsal]

Yes, there is a timestamp applied. And piGallery recognizes those dates for sorting and grouping. Here's a strip to demonstrate. But the assigned blog comments are applied at the wrong places.

[stenrock]

So your comments are correctly applied but if you set a heading then that will be placed in the end of previous comment.

Very strange. I have tried every trick I can imagine but cannot get this problem replicated. It works fine by me.

[Marxsal]

I've tried every single trick I can think of to get this to work correctly, and am even now trying it on a different OS. It just plops the comments down randomly.

[Marxsal]

I gave one of my photos a stamp from 2024 and changed the <!-- @pg-date --> accordingly. Now the blog inserted correctly.

So I would guess that the insert routine is using some file-based logic that doesn't know about dates before 1970. But the date sorting algorithm knows about older dates so is probably using some other toolkit.

[Marxsal]

Very strange. I have tried every trick I can imagine but cannot get this problem replicated. It works fine by me.

Did you create a set of photos with datestamps (exif) before 1970 ?

[stenrock]

No I did not have any photos before 1970 when I checked out this problem the first time.

But now I have done some extensive tests with images having consecutive dates from 1969 up to 1972. It seems strange but in my tests I find that from 1970-04-27 it works just fine. But if any date before that is included it affects where the code for @pg-date makes the text to appear in the wrong place.

Here is a link to a page that starts at 1970-04-26: https://pq45.ddns.net/gallery/share/01e9b9eb
Here is a link to a page that starts at 1970-04-27: https://pq45.ddns.net/gallery/share/553b077a

As unix times start 1970-01-01 I thought that would be the date from which it would work as intended but a lot of testing did reveal 1970-04-27. I hope anyone can explain. Maybe am I missing something.

[Marxsal]

I can only guess that someone re-used date handling routines originally meant for un*x file systems, but then modified them in some strange way.

Photographs go back to the early 1840s.

I suppose historians/archivists have some software for presenting images of items going much deeper into time?

But honestly, the 1960s weren't that long ago. No mammoths roaming around or pterodactyls in the skies.

[Marxsal]

Aaargh! The situation is worse than I realised. I've given up on dates-per-section and removed the pg-date tags. But now it wants to put the directory .md note just above the last group in the gallery instead of at the top where it would make sense. So it wants to sort even notes without dates as though they had dates when dealing with photos before the 1970s.

It was such a nice possibility of a feature. It's a shame it isn't properly supported.

[kagahd]

That's an Interesting issue! The reason becomes obvious when looking at the numerical presentation of the dates:

• 1970-04-26 = 9936000000
• 1970-04-27 = 10022400000
• 1970-11-01 = 26265600000

I first suspected the culprit in the “10-digit rule” which is to distinguish seconds from milliseconds when normalizing timestamps. In many systems, a timestamp value less than 10^10 is assumed to be in seconds, whereas a larger value is assumed to be in milliseconds. But this assumption did not hold true since PiGallery2 uses dates properly transformed to milliseconds.
The reason is even simpler, but well hidden in the blog.service.ts.
The line dates.sort(); does not look suspicious at all unless you know that the JavaScript sort() method sorts values lexicographically (as strings) rather than numerically even if dates is an array of type number. This leads to incorrect sorting of timestamps. The solution is to provide a numeric comparison function like sort((a, b) => a - b) to ensure proper chronological sorting.
PR #996 solves it.

[Marxsal]

I noticed that some scripts ran when you submitted your PR.

How hard would it be for a mere mortal to apply your patch and build a new image. Or whatever Node artifact needs to be inserted into the existing docker image (it's unclear which one gets built). I note that it's been 7 months since the last release so it might be awhile before a new release.

Thanks!