While installing Postgresql DB 13.0-1 x64 on Windows, if I comment the "timezone" key on postgresql.conf file then "show timezone" sql query gives me "GMT".
How could I do for the timezone to be the same than my Windows OS's timezone automatically, without running the "ALTER timezone" query manually myself ?
Thanks
PostgreSQL does not try to determine the operating system time zone when the server is started, but when the database cluster is created with initdb.
During initdb, PostreSQL tries to determine the correct IANA time zone from the operating system. See this excerpt from src/bin/initdb/findtimezone.c:
/*
* The following block of code attempts to determine which timezone in our
* timezone database is the best match for the active system timezone.
*
* On most systems, we rely on trying to match the observable behavior of
* the C library's localtime() function. [...]
*
* Win32's native knowledge about timezones appears to be too incomplete
* and too different from the IANA database for the above matching strategy
* to be of any use. But there is just a limited number of timezones
* available, so we can rely on a handmade mapping table instead.
*/
[...]
/*
* This list was built from the contents of the registry at
* HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Time
* Zones on Windows 7, Windows 10, and Windows Server 2019. Some recent
* additions have been made by comparing to the CLDR project's
* windowsZones.xml file.
*
* The zones have been matched to IANA timezones based on CLDR's mapping
* for "territory 001".
*/
{
/* (UTC+04:30) Kabul */
"Afghanistan Standard Time", "Afghanistan Daylight Time",
"Asia/Kabul"
},
{
/* (UTC-09:00) Alaska */
"Alaskan Standard Time", "Alaskan Daylight Time",
"America/Anchorage"
},
[...]
{
/* (UTC-07:00) Yukon */
"Yukon Standard Time", "Yukon Daylight Time",
"America/Whitehorse"
},
{
NULL, NULL, NULL
}
The code then calls localtime(time(NULL)) and gets the system time zone name using strftime() with the format %Z. If that matches an entry in the above list, we are done. Otherwise PostgreSQL scans the HKEY_LOCAL_MACHINE registry entries under SOFTWARE\Microsoft\Windows NT\CurrentVersion\Time Zone for a match. If none is found, GMT will be used.
That value is stored in postgresql.conf and determines the default time zone. If you remove that entry from postgresql.conf, PostgreSQL will fall back to the default value GMT.
So the solution is not to remove the entry from postgresql.conf, but to run initdb when you need a database cluster on a new machine.
Related
I saved a record in 17:16:15, I run a job which gets the ModifiedOn field of my record and I got- 15:16:15, my GMT is +2, I want to know how to fix that gap that my result will turn out like it should be - 17:16:15. I can't select it from DB I need a solution in server side (c# I mean) what can U do in that case?
DateTimes are always saved in UTC in the database. *
You need to dynamically convert from UTC into your local time zone. In C#, you can do this with the .ToLocalTime() method as long as your code is running in the correct time zone. You can also find your local time in the FormattedValues collection of the response, which uses your Dynamics timezone user settings . But the raw datetime value in the database will always be in UTC.
* The only exception to this is if the DateTime field is set to “TimeZone Independent” in the attribute type settings. But be careful: once you set this option you can’t change it for that field again.
I am currently storing events of some entities in UTC time but I am not sure if I should do that in this case. Imagine there's an event at 10pm local time (-4h UTC) and a mobile App fetches "todays events". This could e.g. look like this:
App sends request to fetch all clubs in the near location
After receiving all clubs it sends a request to get all events for today. It therefore sends the local time Sun. 10pm to the server.
The server would convert the local time of the mobile device to UTC Mon. 1am and fetch all events from Monday. But of course that was not what I wanted.
Fetching all events from the clubs and convert them to their local time using their local time offset information is not really a great solution.
So wouldn't it be better to just store all events in local time? In that case the mobile App would send its local time to the server which would be able to query all events from the clubs in local time as well.
This sounds much simpler to me but I am not sure if I overlook something.
So what would I do in this case?
Yes, storing everything in UTC is probably the best solution.
You don't say how you are "storing" the dates/times, but if you are using Dates or Joda equivalents, then you should know that their underlying representation is effectively in UTC (they represent a moment in time as an offset in milliseconds since the "Epoch", which is Midnight, Jan 1, 1970 UTC). These dates only have a timezone when you format them as Strings.
Most databases do something similar (store the date in a common timezone, usually UTC). The major exception that I've found is the generally available date-time related column types in MS SqlServer which by default store everything in the local timezone of the server.
Also be aware that if you use SQLite, and you store a date/time by passing a String in SQL that contains a timezone, SQLite will store it without warning, but will ignore the timezone and assume that the timezone is UTC, giving you a result other than what you might expect.
For more on this, see my (old) blog post at http://greybeardedgeek.net/2012/11/24/java-dates/
The other answer is correct. Some more thoughts here.
A time zone is more than the offset from UTC mentioned in the Question. A time zone is also the set of past, present, and future rules for anomalies such as Daylight Saving Time. You should refer to a time zone by its proper name, continent plus Slash plus city or region. Never use the 3-4 letter codes such as EST or IST.
To search for events in the user's "today", you must know the user’s time zone. For example, a new day dawns earlier in Paris than in Montréal. After the stroke of midnight in Paris we still have a few hours of “yesterday” left to go in Montréal.
While you can make a guess as to the user’s time zone, the most reliable way is to ask the user.
DateTimeZone zone = DateTimeZone.forID( "America/Montreal" );
DateTimeZone now = DateTimeZone.now( zone );
DateTime today = now.withTimeAtStartOfDay();
DateTime tomorrow = today.plusDays( 1 );
// Search for events that start >= today AND that start < tomorrow.
To search Joda-Time objects, use the Comparator built into DateTime. That comparator works across objects of various time zones.
To query a database, convert that pair of DateTime objects into java.sql.Timestamp objects. You do that by extracting and passing the count of milliseconds since the epoch of 1970 in UTC.
long m = today.getMillis();
java.sql.Timestamp tsToday = new java.sql.Timestamp( m );
I have a very weird problem with Catalog Price Rules. As you know normally when price rules are applied, they are applied for current day, past day, and next day.
The problem is that the price rules are generated only for current day, and two past days.
So if taking today example on catalogrule_product_price on rule_date row the dates set are:
2014-03-12
2014-03-13
2014-03-14 - today date
Instead of:
2014-03-13
2014-03-14 - today date
2014-03-15 - tomorrow
Any suggestions?
This happens when your database is using a different time zone to your Magento site. You need to check and verify that they are both using the same time zone.
For Magento you can check this from System -> Configuration -> Locale Options.
For your database, you can run the following query to the the current local time: SELECT NOW();
If these don't match then you will get the behaviour described above (rules are not correctly set +/- current day). Most likely you need to correct the timezone that your database is using.
Edit: it seems that the best way to handle this is to ensure that you set the global timezone to UTC in Magento, and then set the timezone for your individual site(s) to the local time in your region. Your database should also be set to default to UTC.
Edit 2: Also make sure that the default locale set in app/etc/config.xml is correct.
Could it be related to time zones? Either the time zone of your server clock or the time zone set in Magento?
Try setting your Default Store Timezone to match your server timezone.
My Linq query of DateTimeOffset column always throws InvalidTimeZoneException. The data appears to be correct. Any idea what's happening?
Details:
Oracle Column: CREATED_DATETIME TIMESTAMP(0) WITH TIME ZONE
EF MAPPING: public Nullable<System.DateTimeOffset> CREATED_DATETIME { get; set; }
DataAccess: ODP.net Oracle.DataAccess
Data Sample: (Timezone column available but not used)
CREATED_DATETIME TIMEZONE_NAME
8/16/2013 5:06:05 PM +00:00 US/Central
8/16/2013 5:35:06 PM +00:00 US/Mountain
Code:
var q = from isr in pc.ISRs
select isr.CREATED_DATETIME;
try
{
DateTimeOffset? value = q.First();
}
catch (InvalidTimeZoneException tze)
{
throw new ApplicationException(tze.Message);
}
catch (Exception e)
{
throw new ApplicationException(e.Message);
}
var orders = from o in q select o;
Oracle's TIMESTAMP WITH TIME ZONE type, (aka TIMESTAMPTZ) is a funny creature. It stores a date, a time, and either a fixed "time zone offset" or a "time zone region name".
When there's a fixed offset, then the DateTimeOffset type in .Net would be a good match, and it is not surprising that Entity Framework is using that as the default. (Although technically, the mapping probably comes from the underlying ODP.net provider rather than from EF.)
But when it's a time zone region name, there are going to be issues:
Those time zone names are IANA time zones, and aren't usable directly with the TimeZoneInfo class. They would need to be translated. See the section on time zone databases in the timezone tag wiki.
.NET doesn't have any type that represents a DateTime or DateTimeOffset paired with a time zone.
The Oracle data doesn't actually include the time zone name. Instead, it includes a pointer back to an id in the system data within the Oracle database. So any resolution of this name from the raw bits would have to be done while a connection to the database was still open. Not to long ago, I answered a question about this and how it relates to Java. You can read my response here, which mostly applies still for .NET. (Although I'm sure the implementation is quite different in ODP.net.)
It's worth pointing out that the Noda Time library includes both IANA time zone data, and the ZonedDateTime type, which could fully represent an Oracle TIMESTAMPTZ. There is no direct mapping, but I suppose it should be possible to construct a ZonedDateTime when calling your Oracle database.
However, there is currently no support for Noda Time with Entity Framework, so that would get in the way here. (That is on my agenda, but I have not looked into it very deeply yet.)
So most likely, the only way you will be able to use the TIMESTAMPTZ type within Entity Framework is to make sure you are using fixed offset zones only. Using it with an Oracle "time zone region name" is not going to work. At least - not yet.
It's a shame really. The region names are a nice feature, because then you are automatically getting the benefit of daylight saving time changes being incorporated into the calculation.
We have a reporting application where all DateTimes are stored in UTC in the database (SQL server 2005)
The reporting application works simply be retrieving a DataTable and binding to a DataGrid displaying the information.
If we know the logged in users time zone (e.g. +3 GMT), is there any way to update the DataTables dates which are in UTC to now display in the users time zone?
We know we can spool thorugh each column/row in the DataTable and do a conversion but is there a better more efficient way?
I would modify the time as it is displayed to the user. Keep how it is stored consistent, but also store what their timezone is, and then modify the UI to show the correct local time. For example, if their time zone is Central Standard Time, then you could use something similar to the following code:
SomeDataObject someDataObject = new SomeDataObject();
someDataObject.TimeZone = -5; //UTC Timezone for Central Standard Time
someDataObject.Time = DateTime.Now;
DateTime someTime = someDataObject.Time;
someTime.Add(someDataObject.TimeZone); // Display this back to the user
If using .NET, there's a built in class that was made precisely for this purpose. TimeZoneInfo (http://msdn.microsoft.com/en-us/library/system.timezoneinfo.aspx) as taken from the article:
A TimeZoneInfo object can represent any time zone, and methods of the TimeZoneInfo class can be used to convert the time in one time zone to the corresponding time in any other time zone. The members of the TimeZoneInfo class support the following operations:
Retrieving a time zone that is already defined by the operating system.
Enumerating the time zones that are available on a system.
Converting times between different time zones.
Creating a new time zone that is not already defined by the operating system.
Serializing a time zone for later retrieval.
Hope this helps.