I'm currently having an issue with the wrong timezone displaying on a web page. I support a Linux environment for a small app development team. Currently we are testing a particular app. For test purposes we have a simple web page showing that the app is live and working. The page itself displays the project title and server time.
This issue is that the web page displays the incorrect timezone, however the time itself is correct.The text displayed is "The time on the server is April 5, 2018 7:18:04 AM CDT." For context I've included a screen shoot.
time zone issue
Nothing special going on here. As I said the time is technically correct, but it's displaying Central time when I need it to show Eastern, because the people using the app will be located in the Eastern timezone.
I support the environment itself and am not a developer. However, after speaking with them they ensure me that whatever method is being called is pulling from the server time. I've tested this successfully and am able to manually change the time on the server that it is hosted on, and the web page will reflect that.
Within the environment we are using CentOS 6. Based on my research the timezone information is handled by the file "localtime" within the "etc" directory. I've used several methods to alter this file.
I've tried the following command:
cp /usr/share/zoneinfo/Eastern /etc/localtime
I've also tried variations of the command. The server shows the correct time and timezone, but the timezone displayed on the web page never changes.
We have two servers to host apps. The interesting this is that apps that are hosted on the other server are being displayed correctly with the Eastern timezone. I've also tried simply taking the "localtime" file on the correct server, and copying it to the other server within the /etc/ directory. With each attempt doing a server restart.
I realize this is a simple issue, but after trying multiple methods with no success I thought I would seek assistance. Any help is appreciated.
Related
I just wrote a little piece of code to show the server time in a webpage. At the moment I just have one machine so I cannot test if the code is working.
Is there a way to tell the browser to use a time configuration different from the one configured in the OS? I have used plugins for Firefox to test different locales, I wonder if there are similar options for time tests.
Thanks.
Create a new empty directory for a separate Chrome user profile. E.g. with
mkdir ~/chrome-profile
You specify the TZ environment variable. You can see the valid timezones for example here, in column TZ.
To start Chrome, use these commands:
for Mac OS X: TZ='US/Pacific' open -na "Google Chrome" --args "--user-data-dir=$HOME/chrome-profile"
for Linux: TZ='US/Pacific' google-chrome "--user-data-dir=$HOME/chrome-profile"
Unfortunately, JavaScript is only aware of the current time zone, as it is set by the operating system. There are no facilities to let the Date object use a different time zone in a particular context. There are some libraries to do time zone conversions, but that won't help for what you are asking.
On Linux, Mac OSX, and other *NIX systems, you can set the TZ environment variable. See Benedikt Köppel's answer for details.
However, there is no facility for this on Windows. Some Windows programs may pick up on the TZ environment variable, but those that do will not necessarily interpret it correctly, as they aren't wired up to support IANA time zone names. More on this here and here.
You don't need to change OS variables or extensions to do this in 2021.
Chrome Dev Tools > Hamburger Menu > More Tools > Sensors
On the Location section select your location or give it a timezone id (e.g. America/Chicago, America/New_York)
On popular demand (kidding!), the explanation.
Google Chrome reads the environment variables to get the timezone its running in. Apparently all instances of Chrome share the value (not tested). In order to force a timezone, we need to a) set the environment variable to the timezone we want, b) kill all existing instances of Chrome, c) Print the current timezone to confirm, and d) Start Chrome with the intended timezone.
The below shell script is tested with OS X but should work for others too.
export TZ='US/Pacific'
killall Chrome
date
open /Applications/Google\ Chrome.app
Chrome seems to update its TimeZone as soon as you change it in Windows. Firefox seems to store the timezone value of the system at startup.
With Visual Studio it looks like you can turn the trick on its head. It seems that the Timezone is only read when you first start the debug process. So In my case, what I did was set the TimeZone to, for example, Eastern Standard Time. Start the Visual Studio debugger. I then changed the TimeZone to, for example, Pacific Standard time. The server at this point remained in the Eastern timezone, while my browser was in the Pacific timezone. Now I was able to test the client browser behavior just fine.
If you wanted to test a client in Japan, then just update your TimeZone and the browser will follow it. As long as you don't restart the debug process your server timezone will not change. Also just changing the time (as opposed to the timezone) did not work.
There is a lot of time zone extensions available to spoof in browser level. I am using currently
After adding click option of the extension and check
Once both done, Go to any website and open developer tools and check by executing below command
new Date().toLocaleTimeString()
Old question, but I had a similar issue and I'll throw my fix in anyways.
What I did was run my server in a virtual machine, set the network settings to bridged so that I'd be able to access the server from my host OS as the client easily.
I then changed time settings in the VM so that there was whatever difference I wanted between the client and server.
Maybe it will help someone. You can change time zone for Windows 10 using this steps:
Open Settings.
Click on Time & Language.
Click on Date & time.
Change time zone to your need.
P.s. According to the #Oscar Acevedo comment this answer is not quite correct. It's suitable for testing different time zones.
This an easies way I tried to chang time zone and test it for windows 7 ^
I use tzutil
tzutil /s "Eastern Standard Time"
and save it to suitable .bat file e.g Eastern_Standard_Time_zone.bat and use default_time_zone.bat conain your original system time zone to get it back after finishin tesing . this will change your time zone in blink .
reference
If you are into reproducibility, I suggest that you use an e2e environment, i.e. tooling that can automate browsers and allows to manipulate their time zone.
That way you won't have to fiddle around with the system time zone and you can add tests, that specifically do use different time zones, i.e. you can test your code in different time zones.
Two of the most recent popular libraries for browser automation, Puppeteer and Playwright explicitly allow setting the time zone. Using Playwright you get the ability to automate setting the time zone for all major evergreen browsers (Safari, Firefox and Chrome / ChromeEdge):
for Puppeteer you have to use page.emulateTimezone
for Playwright you have to use a newContext
You're probably better off leaving your computer timezone intact and changing your server settings to reflect a timezone ahead or behind of you. This is usually pretty easy to do depending on the server you're using.
I am building a static app with PouchDB on Google AppEngine.
When I open the site in a browser window, it is showing a version I uploaded several hours ago.
If I open the site in an incognito window, the updated version is displayed (therefore I don't think it is actually an error in the console).
I put a new version number in app.yaml
I have migrated all traffic to the new version.
I have cleared my cache, deleted cookies, checked my application data, everything. I even reinstalled Chrome and Firefox.
I updated my Python version and my Google AppEngine Launcher yesterday; the problem pre-dated that update.
Also: just discovered that if I go to the URL of the updated version
http://4.[app-id].appspot.com, it displays the correct, updated version.
This is happening in Chrome, Firefox, and Edge.
Edit: probably should have mentioned that my site uses Service Workers and IndexedDB. I assume my service workers are caching the previous version, but I would have thought that Ctrl + F5 would clear the cache and show the new version.
I think it must be the Service Workers caching the pages (which is, after all, what they are supposed to do). This is actually really annoying when you are developing though.
A guy called Rich Harris has documented this behaviour and some workarounds on a Github Gist.
Reloading the page doesn't behave as you'd expect
If you make a change to your service worker, then reloading the page
won't kill the old one and activate the new one (it detects the change
by requesting the service worker file each time and comparing the old
and the new byte-for-byte), leaving you somewhat confused as to why
your changes haven't taken effect. This is because the old window is
never actually closed, meaning there's never a time to swap them out –
you need to kill the tab completely then reopen it.
Or you can have the browser do that for you by going to the
Application tab in devtools (in Canary, not stable Chrome yet), going
to the Service Workers section, and checking 'Update on reload'.
UPDATE (13 Nov 2017): This functionality is now available in Chrome, so you don't even need to download Canary.
And here's which bits of the application cache to clear:
I am using Umbraco 7.5.2, installed on a VM in Azure.
When a Publish At date is set, the page is never published. I have tried the following steps.
Create and publish a page
Unpublish the page
Set the Publish At date to a few minutes in the future and Save&Publish
Verified page is definitely not visible
Wait for the time to roll around, and even a few minutes more
Page is never published.
The following message appears in the logs on save when setting the publish at date, which is normal. But no other messages appear after and the page is never published.
2016-10-25 17:46:20,784 [P4808/D10/T21] INFO Umbraco.Core.Services.ContentService - Content 'Video1' with Id '1312' is awaiting release and could not be published.
I've made a copy of my production Umbraco folder and of the database ON THE SAME VM. That instance works for scheduled publishing.
I'm wondering if anyone can provide some clues as to what the issue could be or where I could look. I'd like to avoid having to migrate my production data to this test site.
Thanks
The problem may be related with different time-zone on azure VM as Umbraco is using server time to proceed inside the code execution. This should be the first thing to check.
In version 7.6.0 (https://our.umbraco.org/contribute/releases/760) it will be possible to set up server timezone and then set up a time with precise offset, so those type of problems shouldn't be seen then.
For me it was a wrong umbracoApplicationUrl path (it has to point to YOURDOMAIN/umbraco) After fixing this url everything started working fine
In addition to Marcin's answer, also check that the server can access itself, as it pings itself to fire the scheduled publishing. If it can't resolve it's own address, the scheduled publish will fail. It doesn't happen often, but I've seen a few VERY locked down installs where the server can't resolve it's own address.
I am sorry but I am relatively new to the programming world and have run into an odd issue that I cannot overcome. At my company we use an open source ticketing system called Clocking IT version 0.99.3. Unfortunately, there does not appear to be any formal support for this program anymore which is why I am posting here. The issue that we are having is after the year change from 2014 to 2015 the login page no longer redirects to the home page after successful login, rather it redirects back to the login page to have you supply credentials again.
I validated this theory by setting the system time and date back to 12/31/2014 16:00:00 and can successfully log in, but if the date and time are restored to current that there is not successful login.
From what I know of the system, it is running in Linux using Apache / Ruby / and MYSQL. I have evaluated the login_controller.rb file and cannot find anything that stands out as the issue. I appreciate any advice that you guys can offer and can retrieve logs or configs upon request. Thank you.
I had the same problem and I figured out the solution, edit the file /var/www/html/cit/config/environment.rb with command vim.
search the line below
ActionController::Base.session_options[:session_expires]= Time.local(2015,"jan") and change for
ActionController::Base.session_options[:session_expires]= Time.local(2035,"jan"), salve the file e restart the application.
Problem solved.
regards
André Paulino
Recently I've run into the issue that the public files of a rails application only load if there is a cookie present. I originally noticed this because Google reported that it couldn't find our robots.txt file. Later I realized that it seems to apply to all of our public files for some reason.
For instance, upon visiting this site, the content is blank. http://80000hours.org/robots.txt
(If it's not blank, remove the cookies from the website).
However, when I load the main page at http://80000hours.org/, and then go back to /robots.txt, the page loads correctly.
I'm quite confused what could create this issue and how to go upon debugging it. Looking back on my commits it doesn't seem like I changed anything substantial during the period where it broke. The Memcache add-on for the website shut down around a week before this happened; I never set up a replacement, but wouldn't think this would have caused the issue.
The issue also does not exist locally, only on the production and staging Heroku instances. The full codebase is here, the issue occurred around November 14th.
Any advice is much appreciated.
Sure enough, it was Memcache. I added the new Heroku Memcache add-on service, Memcachier, and it worked fine without the cookie. I'll check tomorrow if Google successfully find the /robots.txt file or not, but I'm assuming it will.