Hello!

The session date in the table is in the following

..................session_date = 992952420 or 992945106 etc.

further.....

In the users_join_time shows like = 988752797

Also, users_last_login shows = like 992450417.........

I may be wrong but I have never understood this. Should it not show the correct time stamp everywhere? Is it something that I need to change to get it correct????

Thanks

Hi,

This is not a bug. This is normal. Gossmaer Mail is using unix timestamps for easier manipulation of time.

Cheers,

Alex

--
Gossamer Threads Inc.

Hello Alex!

Thanks for all your replies and help.

But then how do I know the date of the user+function? I mean, when on which date did the user join, etc.

Hi,

It should display correctly in the admin area of Gossamer Mail. In mysql If you want to find it by selecting it from the table, you can do something like:

SELECT FROM_UNIXTIME(users_last_login) as time_logged_in FROM users;

Cheers,

Scott

Hello Scott!

Thanks for the reply.

I beleive I am missing something. Or an understanding problem.

After selecting the user through search or modify from admin, it shows the following:

Last Login : 993070520
Creation Timestamp : 993070520

Now I do not have a lot of experience but how can one understand this in terms of human known dates?

Are the UNIX_TIME always like this? I thought there would be real dates inserted in there? If not, can one?

Yes, I would love to see dates written with humans in mind too. The existing timestamp is next to useless which is very frustrating. You can't even change it to something more memorable. It may not be a bug, but I think it should be changed.

Also setting user limits in bytes is a bad idea. The old megabyte system was easier to manage without having to get your calculator out. You see 5000000 doesn't actually equal 5 megabytes, so you promise users a 5 meg account, but they actually see something like "You have 4.65543 megabytes remaining".


Regards

Jason

Hi,

Ah, this is a bug that will be fixed in 2.0.1. If you are using table prefixes, the timestamps aren't being converted automatically. It was never intended behavior.

Cheers,

Alex

--
Gossamer Threads Inc.