|
Author: andy
Date: 21-05-03 09:32
Hi Dan,
I visit fresh ports at least once a day. I am only really interested in what has changed since I last visited, but the timestamps do not match my timezone (nz). This can make it harder to remember where I was last up to.
Any thoughts?
|
|
Reply To This Message
|
|
Author: JunkMale
Date: 21-05-03 11:10
So is the issue:
- commit times not being displayed in local time
or:
- not knowing what commits have appeared since you were last here?
--
Dan Langille - webmaster
|
|
Reply To This Message
|
|
Author: andy
Date: 22-05-03 06:48
Well, either will solve it really. If I had to choose one, displaying commits in my localtime would be the cooler option.
|
|
Reply To This Message
|
|
Author: andy
Date: 22-05-03 06:52
I didnt actually answer your question. :-/
The issue for me is: (issue is a bit strong, call it a wishlist)
-not knowing what commits have appeared since you were last here?
But having the commits in localtime would solve the above for me with the added bonus of knowing what time it happened.
Andy
|
|
Reply To This Message
|
|
Author: JunkMale
Date: 22-05-03 10:51
Andrew wrote:
>
> But having the commits in localtime would solve the above for
> me with the added bonus of knowing what time it happened.
Commits in localtime may not be trivial to solve. Two values are needed:
- The commit time (known, easily obtained from the database, and already sent to the client browser).
- The hours difference between server time and client time. This is not a fixed value. For example, New Zealand is sometimes 13 hours ahead of PST and sometimes it's 15 hours ahead of PST. And it might even be 14 hours ahead at some times.
I'm hoping someone will code a solution, either server based or client based.
--
Dan Langille - webmaster
|
|
Reply To This Message
|
|
Author: AnotherJunkMale
Date: 14-11-04 06:15
JunkMale wrote:
> - commit times not being displayed in local time
Or even just document the server timezone (or use UTC).
Currently the times being displayed are one hour off of UTC.
|
|
Reply To This Message
|
|
Author: Dan
Date: 14-11-04 13:43
AnotherJunkMale wrote:
> JunkMale wrote:
>
> > - commit times not being displayed in local time
>
> Or even just document the server timezone (or use UTC).
>
> Currently the times being displayed are one hour off of UTC.
They are now UTC. The one hour off was because of daylight savings.
This issue is not as simple to resolve as it may seem.
Try it yourself.
Create a PostgreSQL database. Dates are stored in a 'timestamp with time zone' field. Ensure your system time zone is set to PST.
dan=# insert into test values ('2004-11-14 13:07:23 UTC');
INSERT 8834308 1
dan=# select * from test;
commit_date
------------------------
2004-11-14 05:07:23-08
(1 row)
dan=# insert into test values ('2004-11-14 13:07:23');
INSERT 8834318 1
dan=# select * from test;
commit_date
------------------------
2004-11-14 05:07:23-08
2004-11-14 13:07:23-08
(2 rows)
The system uses a time_adjust feature. It was set at -7 hours. It is now set at -8 hours.
A possible solution might be to remove the time zone from such fields and just store the time as found in the commit message. Such a solution removes flexibility.
As before, I am open to suggested solutioned.
|
|
Reply To This Message
|
|
Author: AnotherJunkMale
Date: 14-11-04 19:51
Dan wrote:
> This issue is not as simple to resolve as it may seem.
>
> A possible solution might be to remove the time zone from such
> fields and just store the time as found in the commit message.
> Such a solution removes flexibility.
>
> As before, I am open to suggested solutioned.
When I have had to do similar things before I have always preferred to use UTC and store date/time values as a time_t value and do any needed conversions upon use.
Another idea is to run the server or process in UTC instead of PST/PDT.
These are just ideas for consideration, often there are more complexities involved, especially if you are using features of the date data types.
One place I worked once, a VP insisted on using Eastern Time for some reports and I needed to send a reminder email out twice a year explaining why April would have one day with 4% less usages and October would show one day with 4% extra usage.
|
|
Reply To This Message
|
|
Author: Dan
Date: 14-11-04 21:01
UTC is an option. I don't know if I like it enough to try it though.
|
|
Reply To This Message
|
|
Author: Dan
Date: 16-11-04 23:38
AnotherJunkMale wrote:
> When I have had to do similar things before I have always
> preferred to use UTC and store date/time values as a time_t
> value and do any needed conversions upon use.
time_t? FreshPorts stores everything in a PostgreSQL database. At present, it uses a timestamp with time zone. That started in the days when commits were done in PST and my machine was in EST. I thought it best to store the timezone information. It was easier than converting to UTC, or so I thought.
> Another idea is to run the server or process in UTC instead of
> PST/PDT.
I think I may leave the server in PST but change the database field to be without a timezone. The input data is already in UTC, so all I need to do is strip away the timezone and we're done.
I think that idea most because it allows me to let the user specify the time adjustment value themselves, thereby converting UTC to the time of their preference.
|
|
Reply To This Message
|
|
Author: Dan
Date: 17-11-04 00:57
Dan wrote:
> I think I may leave the server in PST but change the database
> field to be without a timezone. The input data is already in
> UTC, so all I need to do is strip away the timezone and we're
> done.
I found an easy way to convert timezones in the database:
freshports.org=# select commit_date, commit_date at time zone 'UTC' from commit_log order by id desc limit 5 offset 90;
commit_date | timezone
------------------------+---------------------
2004-11-15 23:14:28-05 | 2004-11-16 04:14:28
2004-11-15 23:14:25-05 | 2004-11-16 04:14:25
2004-11-15 22:58:29-05 | 2004-11-16 03:58:29
2004-11-15 19:57:44-05 | 2004-11-16 00:57:44
2004-11-15 19:48:27-05 | 2004-11-16 00:48:27
(5 rows)
|
|
Reply To This Message
|
|
Author: Dan
Date: 17-11-04 03:26
Dan wrote:
> I think I may leave the server in PST but change the database
> field to be without a timezone. The input data is already in
> UTC, so all I need to do is strip away the timezone and we're
> done.
I also think I've figured out how to do the conversion.
There are 16 columns to be modified thusly:
dan=# create table a (a timestamp with time zone);
CREATE TABLE
dan=# insert into a values (current_timestamp);
INSERT 46177520 1
dan=# select * from a;
a
-------------------------------
2004-11-16 22:10:08.824097-05
(1 row)
dan=# update a set a = a at time zone 'utc';
UPDATE 1
dan=# select * from a;
a
-------------------------------
2004-11-17 03:10:08.824097-05
(1 row)
dan=#
Here, you can see that the time has changed from being -05 (EST) to being UTC (please ignore the -05). Now, we dump the database, alter the 16 columns to be 'timestamp without time zone'. When the data is reimported, the time zone will be dropped, and we'll have this data:
dan=# select * from a;
a
----------------------------
2004-11-17 03:10:08.824097
(1 row)
That's the theory.
|
|
Reply To This Message
|
|
If you buy from Amazon USA, please support us by using this link.