I have a large table with DateTime values that need to be converted to DateTimeOffset.
I can do this by using the following statement, which retains the date/time and adds the current time zone offset.
TODATETIMEOFFSET([StatisticDateUTC], DATENAME(tz, SYSDATETIMEOFFSET()))
The problem is some of these values represent dates years ago, some in daylight savings, some not, so it's actually incorrect to put the current offset in all of them. Some of them should have an offset of -700 some should have an offset of -800.
If the time zone was consistent for all of the values, how can I get the correct offset? I know how this can be done in .net, as there are a nice set of functions to do it, but I need a pure sql solution, no CLR functions.
If you can upgrade to SQL Server 2016, or use Azure SQL Database (v12), then you can use the new AT TIME ZONE function, which is very similar to the TimeZoneInfo.ConvertTime method you may be used to in .NET.
Otherwise, consider a third-party solution, such as my SQL Server Time Zone Support package, which uses standard IANA time zones.
More on both in this related answer.
Related
I have a Perl Catalyst app that store some times in a MySQL database. The times are of type TIMESTAMP and initialized with NOW().
When reading back the times they appear to be in the databases default time zone. However when using the mysql shell I can easily set the time zone by SET time_zone = '+03:00'; and get the correct local time for my time zone.
Is there a way to set the time one like this in Catalyst or DBIx at run time?
I want to be able to support different time zones, for different users, so just changing the default time zone for the database is not enough. I am also aware that I can format the time in Perl after I get the data from MySQL, but there is so much automation going on with Catalyst, DBIx and Template Toolkit so getting the data correctly from the database to start with would be so much more convenient.
My general advise is to set the datetime in your application, not rely on the datetime of the database server. If you don't need to know which timezone a datetime had when it was set you should store it in UTC. If you need to know the timezone later you need to use a database datatype which supports this like 'timestamp with timezone' in Oracle.
See my answer for Formatting timestamp field for output in TemplateToolkit which seems to be what you're asking.
Is it possible to apply some function (user defined / system) to selected columns automatically, may be binding it at schema level.
My scenario is I am saving timestamps of record saving in each table automatically, for which I have used getdate() as default value of those columns, It was working fine till we had our own hosting. But since now we are moving to shared hosting and don't know in which timezone the servers shall be placed in future, I am using GETUTCDATE() to get GMT time.
Since a lot of procedures / functions are already in place, I am looking for something where I don't need to convert this UTC time to my local time explicitly.
So that my Select * from MyTable shall give me time in my fixed timezone using the function I've created.
Let me know if its possible by any way.
Thanks.
It's not exactly clear what you want to do, but there's no way to replace what the SELECT statement asks for with something else: what you ask for in a query is what you get. Unless you replace a table with a view with the same name, but that probably isn't the best approach.
Using a view or function would still mean you have to change your code anyway, so why not just UPDATE all data to UTC time and then do the conversion in your application code? SQL Server has no idea what time zone a client is in anyway, so it isn't possible to do the conversion reliably on the server side. Unless perhaps the client sends the local time zone to the server as a parameter or in CONTEXT_INFO, but there wouldn't be much point because doing it in the client would be simpler anyway.
And of course handling it all in the application will give you a much more flexible, robust solution.
Is there MySQL equivalent to Oracle's TIMESTAMP WITH TIME ZONE?
I need to map a Oracle table, which has some columns with that datatype, into a MySQL table but I can't seem to find an easy way to do this without resorting to some MySQL functions.
Thanks and best regards.
No, you'll need to split the data into 2 columns, one a datetime, and the other holding the timezone information. But what you put in the latter field is dependant on what you've got stored in Oracle - the TIMESTAMP WITH TIME ZONE Datatype can contain the TZ offset and (optionally) the time zone region. Obviously the latter is a requirement for the date time to be semantically correct, but IIRC Oracle does not enforce this data being populated.
without resorting to some MySQL functions
Since MySQL doesn't have the datatype, it'll be very difficult to write MySQL function to process it - it's a lot simpler to create a MySQL compatible representation in Oracle where the datatype is supported. You just need to work out what data you've actually got and decide how you want to represent it in MySQL. By convention that means storing it in UTC along with the TZ in a seperate column, then convert it on selection with the convert_tz function (always from UTC)
MySQL always store timestamps as utc. Dates are always stored without timezone information.
You can configure mysql to return values from now() in different timezones.
To store the current offset you need to add this to some column on your own.
Whats the best way to accomplish changing the timezone of an app? The way I see it the following must occur:
Server TZ is changed by sys admin
mysql must be restarted.
every time based column in the database must have all values updated, using convert_tz or equivalent. So either a mysql script must be written or a grails script that loads every row for each class, updating all the time fields.
Obviously the server should be taken down while this is happening, and backups must be in place incase of an error.
Is there a better/easier way to do this?
Java does not use time zones when using Dates; it stores everything as UTC and only uses time zones when displaying dates. see the following link for a discussion of java date/time.
http://www.odi.ch/prog/design/datetime.php
If you're using the Date, Time, or DateTime column types in MySQL, time zone does not matter.
If you’re using the TIMESTAMP column type, time zones may matter since the TIMESTAMP is stored as a UTC but has conversion done when both retrieving and storing the values. For a discussion of MySQL time zone behavior see
http://dev.mysql.com/doc/refman/5.1/en/time-zone-support.html .
If you’re worried about synchronizing objects across multiple servers in different time zones things get more complicated, see the following thread for a discussion of this.
http://www.pubbs.net/201006/grails/2500-grails-user-how-to-get-gorm-to-store-dates-as-timestamp-in-utc-by-default-without-a-custom-hibernate-mapping-or-joda-time-plu.html
I know this is an old question but I think it's also pretty timeless... at least, I have stumbled upon it a fair number of times recently... so I thought I would contribute my solution.
First, I am using Grails 2.5.1 and PostgreSQL 9.4 as the backend.
Second, Date fields in Groovy/Grails are stored as timestamp without time zone in PostgreSQL. So it seems to me the first answer above is not actually fully correct - the date is not stored in UTC. This observation got me thinking... along the lines of "well if the database doesn't know what the timezone is, who does"? And the first answer that came to mind was "maybe it's Spring".
Third, the specifics of my problem is that I have a lot of dates that I bootstrapped into the database via BootStrap.groovy and new ThisClass().save(). And because these were dates, not dates + times, they all look like 2005-11-03 00:00:00 as PostgreSQL timestamps (without timezones).
Fourth, what really made the penny drop was when I edited one of my GSPs to include the timezone in the date format string, which showed up as PST (where my server is); and when I included timeZone="Asia/Kolkata" in the g:formatDate of the field in question, the time advanced by 12h30. So pretty clearly my server was running in PST8PDT and since that wasn't PostgreSQL I came back to Spring as the potential place to change things.
Fifth, after reading a few comments about setting the locale in grails-app/conf/spring/resources.groovy I decided to try setting the locale and timezone there, as per:
// Place your Spring DSL code here
beans = {
// from http://stackoverflow.com/questions/1569446/grails-how-to-change-the-current-locale
localeResolver(org.springframework.web.servlet.i18n.SessionLocaleResolver) {
defaultLocale = new Locale("en","IN")
java.util.Locale.setDefault(defaultLocale)
println "configure spring/resources.groovy defaultLocale $defaultLocale"
defaultTimeZone = TimeZone.getTimeZone("Asia/Kolkata")
java.util.TimeZone.setDefault(defaultTimeZone)
println "configure spring/resources.groovy defaultTimeZone $defaultTimeZone"
}
}
I also used g:format timezone="Asia/Kolkata" format="dd MMM, yyyy a z" for all my date fields. And that seems to interpret all data in PostgreSQL timestamp fields in the correct timezone and at the anticipated hour (ie the hour that was entered), even though the dates were first entered "in the wrong time zone".
Sixth, g:datePicker - I read a number of posts about making this "time zone sensitive", but I found that its dates are interpreted as in the timezone used by Spring and so in my case, this is exactly what I need. Conversely, if someone wanted to enter dates in their locale and have Spring convert them on the fly to the server's time zone, I guess that would require some extra effort.
Personally I think it would be really cool if g:datePicker accepted timeZone as a parameter and used it in the same way g:formatDate does.
We had problems with time differences between using GORM and using groovy.sql.Sql (for quicker data import).
GORM was using the grails config timezone (UTC) that we set in the Bootstrap, but groovy sql was using the default system timezone (GMT).
The problem was solved by setting the timezone in the $JAVA_OPTS, although you could add the switch to grails opts or to the run-app command.
grails -Duser.timezone=UTC run-app
I have a data structure where an entity has times stored as an int (minutes into the day) for fast comparison. The entity also has a Foreign Key reference back to a TimeZone table which contains the .NET CLR ID Name and it's Standard Time/Daylight Time acronyms.
Since this information is stored as time-zone insensitive - I was wondering how in LINQ to SQL I could convert this into a UTC DateTime for comparison against other times that will be in UTC.
Just to be clear this conversion has to be done server-side so that I can execute filtering on the SQL Server and not the client. The reason for this is to ensure we take into account DST for time zones that support it.
I am using .NET 3.5 SP1 and SQL Server 2008.
Ideally, times should be stored in the database in UTC, and only converted to some local timezone (which would include a DST factor where appropriate) for display. This is especially true if "fast comparison" is your goal.
You might find it easiest to add an extra field which contains the UTC time, modify the clients to add this information, and run a script which one-time calculates it for existing entries.
I can store a CurrentOffset field that will need to be updated by a script that will be updated on the hour, every hour to determine the contextual offset.