I deployed the application on normal windows 7 machine as it is central machine for official use. this is internal use application. bu the datetime manipulation on the deployed machine not working properly. since everything if working properly on development machine. I thought it might be the Regional settings issue but as i settled up same settings on deployment machine same like development machine, still issue is same. issue is deployment machine unable to understand the which is MM and dd. suppose i am sending date like "11-jul-2013" then somehow it converting it to "11-07-2013" this is ok. but date 13 will not work for this case.
Edited: I added
globalization:
fileEncoding="utf-8"
requestEncoding="utf-8"
responseEncoding="utf-8"
culture="en-US"
uiCulture="en-US"
in the web.config. but still problem is same. what should be the issue? really I am stuck.
Sounds like it could be an issue with your culture settings. Try debugging by checking what culture is currently set (CultureInfo.CurrentCulture) right before you are using the date.
Parsing is inherently a difficult operation for dates. From your question, it seems like you are parsing dates from some type of backend (database, server, file, etc). In the case of backend date parsing/formatting, you should always use standard formats. This means using TryParseExact/ToString with a pattern such as RFC1123Pattern and invariant culture. In the case of parsing dates from a frontend (direct user input), the current culture settings should work fine.
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'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.
We have four different environments - dev VMs, dev, QA and prod. All environments have the following setting for the "website" site:
<site name="website" virtualFolder="/" physicalFolder="/"
rootPath="/sitecore/content" startItem="/home" database="master"
domain="extranet" allowDebug="true" cacheHtml="false"
htmlCacheSize="10MB" registryCacheSize="0" viewStateCacheSize="0"
xslCacheSize="5MB" filteredItemsCacheSize="2MB" enablePreview="true"
enableWebEdit="true" enableDebugger="true"
disableClientData="false" loginPage="/" hostName="www.site.com"
enableFallback="true" enforceVersionPresence="true"/>.
So on VM and prod, www.site.com/en/home/press and www.site.com/en/press work.
But on dev and QA, www.site.com/en/home/press works but www.site.com/en/press doesn't work. (Works with startItem but gets a 404 without it).
This is happening with ISAPI enabled and disabled both (no exceptions).
I am not sure what is going on here or where else to look except to make sure that my start item is in good shape which it seems to be.
What can I do to resolve this? If you need more information please let me know.
Thanks
Try looking at the:
"linkManager" tag in the web.config, there is a property called:
languageEmbedding: asNeeded | always | never
which could be set differently on those solutiuons.
If you have Multi-Language website it is recommended to go with
languageEmbedding: always
Advantages :
Some time in IE8 the Language cookie is destroyed, because of that
the language displayed is change randomly.(We have faced this issue
in our environment) LanguageEmbadding : Always will keep the Information and will work without any Issue.
If you have set asNeeded then First time the Language will be displayed and next time onward it will be hidden. But this will create issue with Google Analytics. In GA you will have 2 diff URL with same page content so your analysis will be unnecessarily divided in to 2 pages.
And Yes you can check if there is any difference is Config files. As Mentioned by Martijn you can use the www.site.com/sitecore/admin/showconfig.aspx Copy the Config, compare it using any file compare tool like WinMerge etc.
What is the Hierarchy in your project?
Sitecore-Content-home-Press or
Sitecore-Content-home-Home-Press?
In my project the setting you have mentioned has database = web.
I can't add a comment, but as Martijn says you need to compare the configs. Now this should be very easy since you should be using config include files and so the changes between the environments should be very minimal. If you are not using them then you should start using them, it makes life much easier to figure out the differences from default Sitecore installation and will also make your upgrades much easier in the future. Or maybe you are using them for the other environments and that is what is causing the issue?
All About web.config Include Files with the Sitecore ASP.NET CMS
As for comparing the configs, use a file comparison tool like WinMerge as already metioned, that should weed out the differences much more easily.
Also, as Maulik says, default config has: database="web" content="master"
This seems like config differences. Compare the live configs by using www.site.com/sitecore/admin/showconfig.aspx. This way you can see the actual config which also includes all your /app_config/include/ files
For web development on localhost I'm using domains with .loc extension at the end of a domain name.
For example: if I work on a site roses.com, the local development domain would be roses.loc
(defined in hosts file and IIS as a host-header in binding)
My preferred browser (the main browser I use for development is Chrome) but unfortunately
it does not recognize a domain name with .loc extension as http://rose.loc - it throws me onto a google search page each time I would type in rose.loc (without http://) in the beginning..
Have you experienced this in a similar way ? Is there some solution to that ?
Because during intensive development testing with clearing browser cache and restarting the browser for various reasons, it's getting pretty annoying to be thrown at a google search page instead of the development page where I expect to notice some changes, each time I forget to type in http:// before the url (and Chrome is the one who hides it by default, anyway..)
Google Chrome is pretty "smart" with this. It uses a list of known-good TLDs and assumes everything else is just a search term that happens to end in a dot followed with some characters.
99% of the time that's perfectly fine. It's "only" us developers and a few people with strange network setups that have to suffer for the good of the majority ;-)
You can try using .local as your TLD, as that's a defined domain for referencing local domain names (at least it's used in some mDNS systems).
The issue has been entered as #30636 in the Chromium bug tracker. One workaround that often (but not always) seems to work is to append / to your hostname. So try roses.loc/.
I've created a search engine with a keyword of 'l' (my local TLD is .l). The URL for the search engine is http://%s.l. Then, I simply type "l mysite" in the address bar and it takes me to mysite.l.
Here is a workaround I came up with for this bug: http://code.google.com/p/chromium/issues/detail?id=30636#c38
I have Chromium installed on Linux Mint, and have a few localhost websites here. (I use Firefox for all of my work, so I have just discovered something here with Chromium.) My local sites are called morse and a.z. I had to enter http://morse/ and a.z/ respectively to get these sites to load the first time. They produced quick links on the new tab's otherwise blank page.
After closing Chromium, I reopened it and I could enter just morse/ and a.z to visit these sites. Since I've never seriously used this browser, I have not tailored any settings in it. (I did not use the quick link icons, but instead typed in the address bar.)
My findings confirm the localhost example.TLD/ entry does work when entered for the first time.
About Chromium: I am using Version 106.0.5249.119 (Official Build) for Linux Mint (64-bit).
I've found a dilly of a pickle with a new web server. We have a new web server that is displaying dates differently than our old web servers.
We are running asp classic web pages on IIS 6.0 with windows server 2003.
We have logged in as an administrator and set the regional settings as appropriate and then applied the settings to current user and default user profile.
We then went into registry and update the appropriate formats under HKEY_USERS/.default/control panel/international.
Update the asp.net configuration for our websites to the correct code-page and locale.
Does anyone have other places that the application could be getting date formats from?
I know this isn't the 'proper' way to fix the issue. However, the application was written many years ago, getting something through planning/change control would be a pain, and is the only application running on the server. Thus it is okay to configure the server to cater to this single application. Besides it was driving me crazy that a new server that should be configured identically to an old server was not working.
It turns out that in addition to HKEY_USERS/*/Control Panel/international, there is a setting for non-unicode programs. It can be found under HKLM/system/currentcontrolset/control/nls/language/Default. Set that to the correct code page and it is golden.
On the other hand, if you prefer to not modify the registry directly, you can update all these values through the Regional settings from the control panel.
You can adjust the formats through the 'customize' button.
You can change the 'language for non-unicode programs' under advanced tab.
Just make sure that you check the 'apply to the default profile' at the bottom of the advanced tab.
I don't think the highest vote answer is right, though it's close.
I had to use regedit to change all the internationalization settings of HKU\S-1-5-19\Control Panel\International (NT Authority) and HKU\S-1-5-20\Control Panel\International (Network Service) to match the settings that were already in HKU\S-1-5-18\Control Panel\International (Local System).
This worked perfectly.
I modified all the settings I could see which were different, by hand.
I should think I only really needed to change the settings for S-1-5-20 (Network Service).
Go to Control Panel -> Regional And Language Options, set all options you need, then under 'Advanced' tab select settings for non-Unicode programs and check 'Apply all settings to the current account and to the default user profile.'. Press OK and restart server.
On Windows Server 2008 administrators have additional 'Administrative' tab. There press 'Copy to reserved accounts'.
Classic ASP Defaults to the Locale ID that was configured when the server was Setup. If you have access to the original server run the following code to get Locale ID it's operating under and verify that the new server is using the same.
<%=Session.LCID%>
If the Locale IDs are different and you cannot change it on the new server then you can add a line to the Session_OnStart sub in the global.asa for the application that assigns the correct Locale ID to Session.LCID.
Using an ASP page with the content:-
Response.Write GetLocale
Might be informative, it'll show you what locale VBScript thinks its using.
I've seen issues like this in the dim and distant past when using integrated security. The ASP caches the regional details from a user hive when it first needs to use them then continues to use those settings until the process dies. ASP gets these settings from the user hive associated with the user identity the code is currently running under. Most of the time that would be DEFAULT because the user doesn't have a profile on the system.
However if the user happens to have logged on interactively to the server they will have a profile and so their settings are used. Hence I've seen situations where the server appears to have intermitten problems with regional settings.
I can't recall if I've seen this on IIS6, I've definitely seen it on IIS5.
If you run your ASP application under a different account (not IUSR_Guest)
Login as that account, set date/time format to what you want and restart IIS.