Florin Andrei wrote:
layer to the PHP page that will display those logs and optionally convert the timestamps to local time on-the-fly, if that's what the user wants.
But then you've just moved the DST issue into your application and not really solved much at all :-)
Stephen Harris wrote:
Florin Andrei wrote:
layer to the PHP page that will display those logs and optionally convert the timestamps to local time on-the-fly, if that's what the user wants.
But then you've just moved the DST issue into your application and not really solved much at all :-)
No, that's just to display data, at the last stage, when building the HTML page, it's a read-only operation and it's just for the internal staff. If there are some issues at that level, oh well, I can live with that. :-)
I'm more worried about all kinds of data processing scripts getting confused by the clock jumps and mashing data to a pulp. Using UTC should take care of that. It's really the other clock jump, in autumn, that looks very ugly. The one in spring (a few days from now in my TZ) might be much less cumbersome.
The other way around would be to backtrack through all corner cases and add all sorts of conditions to the scripts to avoid the nasty consequences of the clock going backwards in autumn. But frankly, migrating to UTC seems easier.
--- Florin Andrei florin@andrei.myip.org wrote:
Stephen Harris wrote:
Florin Andrei wrote:
layer to the PHP page that will display those
logs and optionally
convert the timestamps to local time on-the-fly,
if that's what the user
wants.
But then you've just moved the DST issue into your
application and not
really solved much at all :-)
No, that's just to display data, at the last stage, when building the HTML page, it's a read-only operation and it's just for the internal staff. If there are some issues at that level, oh well, I can live with that. :-)
I'm more worried about all kinds of data processing scripts getting confused by the clock jumps and mashing data to a pulp. Using UTC should take care of that. It's really the other clock jump, in autumn, that looks very ugly. The one in spring (a few days from now in my TZ) might be much less cumbersome.
The other way around would be to backtrack through all corner cases and add all sorts of conditions to the scripts to avoid the nasty consequences of the clock going backwards in autumn. But frankly, migrating to UTC seems easier.
-- Florin Andrei
http://florin.myip.org/ _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
where i use to work they would shutdown all schedules at 12:01am and wait until after the time change to restart the schedules again. though this was a shop that had people there 24/7 so they were able to do this.
Steven
"On the side of the software box, in the 'System Requirements' section, it said 'Requires Windows or better'. So I installed Linux."
Steven Vishoot wrote:
where i use to work they would shutdown all schedules at 12:01am and wait until after the time change to restart the schedules again. though this was a shop that had people there 24/7 so they were able to do this.
So, did they turn off crond temporarily, or what?
--- Florin Andrei florin@andrei.myip.org wrote:
Steven Vishoot wrote:
where i use to work they would shutdown all
schedules
at 12:01am and wait until after the time change to restart the schedules again. though this was a
shop
that had people there 24/7 so they were able to do
this.
So, did they turn off crond temporarily, or what?
-- Florin Andrei
http://florin.myip.org/ _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
to be honest i can not remember if they did. what i think they had going is nothing normally ran at that time. but i am not totally sure.
Steven
"On the side of the software box, in the 'System Requirements' section, it said 'Requires Windows or better'. So I installed Linux."
-
Florin Andrei -
Stephen Harris -
Steven Vishoot