im using httpclient and last-modified header in order to retrieve the last updated date of an html file however when i try this on a linux box it returns yesterdays date but when i use a windows machine it returns todays date. is anyone aware of issues using this header field in linux?
Perhaps, linux server has its clock set differently and this way "lives in the past"?
If you dualboot with Windows, you must make sure your Linux system is configured to not think the BIOS keeps the clock in GMT (or UTC), but in local time. Otherwise your Linux system's clock will keep being off when in Linux.
Also make sure that the /etc/localtime file is a symlink to the correct time zone file under /usr/share/zoneinfo.
After configuring those two things, verify your date and time is correct using the date command and set it correctly if it isn't, via:
date MMDDhhmmCCYY.ss
For example, for the current time at my end (19:41:27 on October 15th 2008) I would use:
date 101519412008.27
Just a thought - perhaps your filesystem was mounted with the noatime option. I'm making the assumption here that your html file wasn't modified, only accessed without changes and the 'updated' time wasn't recorded.
Can you see the timestamp of the file? Is it exactly 1 day out, or just sometime yesterday?
when i look at the date assocaiated with the time it is correct, but then the date that gets displayed after i call the http method is one day behind. Possibly a problem with caching
Related
I have a question about BESClient (bigfix ) config.
I want to install and config BESAgent-10.0.0.133-rhe6.x86_64 , using a puppet module to deploy it (on machines with RHEL6,7,8).
And I need know and understand, what does mean this parameter in config file besclient.config "effective date = Tue,%2003%20Nov%202020%2010:16:47%20+0100". I know that this is a timestamp.
I notice that , every time that puppet apply the configs on the machines, this timestamp change.
So , i don´t know if this change in timestamp every time that puppet run on machines, have any bad effect on config.
The effective date only states the time stamp on which the setting was set by the bigfix client. It has no effect on the configuration itself.
Currently I am setting time zone GMT+5 on my Linux CentOS 7 machine by linking /etc/localtime to /usr/share/zoneinfo/Etc/GMT-5.
I want to create a zone info file for example /usr/share/zoneinfo/Etc/GMT-5:30 that enables me to set the current timezone to GMT+5:30 without having to worry about DST changes.
I am aware that I could link /etc/localtime to /usr/share/zoneinfo/Asia/Kolkata for example but then I will have to worry about DST changes even if it may not be implemented in the mean time.
Also I am aware of TZ=GMT+5:30; export $TZ but I am worried that this approach backfire for some reason in the future.
If you don't want to use $TZ variable, you may want to create your own timezone file.
You need create a text file (say MyZone.zic) with
Zone MyZone 5:30 - GMT-5:30
then run
zic -d <desired_folder> MyZone.zic
then link compiled file to /etc/localtime
I've tried setting the timezone as:
export TZ=Europe/Paris
and as:
TZ=Europe/Paris
But none of them work.
The server is setup for UTC time. And it needs to remain that way.
My job needs to happen at 4:00am (Paris time) when the server it not being used. However it happens at 6:00am (because UTC time).
How can I fix this?
As this is flagged with CentOS, I assume that you use cron from CentOS:
https://www.unix.com/man-page/centos/5/crontab/
Use the CRON_TZ variable before a section of rules that you want to run scheduled based on a different time zone.
If you want the commands themselves use that same TZ, then you need to add that to the rules manually.
I have an embedded system where we wish to create custom daylight savings times.
I can achieve this by setting the TZ environment variable, for example: export TZ=IST-2IDT,M3.4.4/26,M10.5.0.
We have several daemons running (eg. daemonA, daemonB, etc.), and if one of those exports TZ then the other daemons won't be able to see it. So that's an issue. A possible work around might be to use a file instead of an environment variable so that 'everyone' can see it.
The GNU C Library manual says the following:
:characters
Each operating system interprets this format differently; in the GNU C Library, characters is the name of a file which describes the time zone.
When I export TZ=:/etc/TZ, and then echo IST-2IDT,M3.4.4/26,M10.5.0 > /etc/TZ, it doesn't work. I see this, when I issue the date command:
Mon Aug 15 04:19:36 /etc/TZ 2016
Is anybody able to give me any clues?
Thanks so much!!
Files such as /etc/TZ depend on the type of system (call them nonstandard as such, though standardization is poor in this area). The usual way timezone is configured is via the /etc/localtime files. Normally these are generated from rule (text) files by the timezone compiler. It is in the tzfile manual page for instance.
The timezone-in-date is a good place to start reading further - since it mentions a few possibilities regarding /etc/TZ. If /etc/TZ is what works for your system, the accepted answer there points to this Oracle page, which appears to document the format.
I need some information from my GPSD server running on my NTP master server.
Amount of satellites it is seeing
Which satellites it is using for the positon fix (maybe also SNR)
Which satellites it is seeing since there are a lott of them (is this possible?)
I am going to output this to PHP, so it must be simple
The GPSD source contains the file gpsd.php which can deliver the current position and satellite info ("skyview") either as a finished HTML page or as a JSON string. So you need to make sure a web server with PHP support runs on your master server and you can call http://ntp-server/path/to/gpsd.php to get it. Append ?op=json to the URL to return the JSON result.
You can get just the php file here: https://github.com/yazug/gpsd/raw/master/gpsd.php
Beat Bolli: I think you meant this one: https://github.com/yazug/gpsd/raw/master/gpsd.php.in (they have renamed it)
It suggests to use ?poll; function, but it hangs to me when I try to read the response...