According to https://debezium.io/documentation/reference/0.10/connectors/postgresql.html#data-types, Dates, Times etc are epoch-relative. Is there a way to override this behavior and return them as ISO 8601 formatted?
That's currently not supported. One option would be to implement a single message transformation (SMT) to change the date field representation. Or you could provide a PR for implementing this functionality in Debezium, this request has come up a few times.
Related
I have to use Fortran for some calculations using data from NetCDF files. And, depending on user selections, I need to select only one or some months from each year.
The dates in the NetCDF file are coded sometimes as "months since XXXX-XX-XX", other times as "days since XXXX-XX-XX", others as "hours since XXXX-XX-XX XX:XX", etc.
In addition, these have to be interpreted as belonging to a certain type of calendar, which can be Gregorian, Julian, proleptic Gregorian, 360-day, etc.
After many searches I have a plan to attack this problem, but want to ask the experts before.
My plan is as follows:
Use the UDUNITS package to convert the date information contained in the NetCDF file, to a Julian/Gregorian date. For this, I have to:
Bind the C code of UDUNITS to Fortran.
Convert the date obtained, to the desired calendar. For this, I think that I have to use a calendar package. Which would be a good choice?.
Do you agree with this?
I think I have found a good solution: the cdi libraries, developed by the Max-Plank Institute and distributed under the GNU GENERAL PUBLIC LICENSE Version 2.
It defines the following types of calendars: CALENDAR STANDARD, CALENDAR PROLEPTIC, CALENDAR 360DAYS, CALENDAR 365DAYS and CALENDAR 366DAYS.
This seems to be a very proven code, since it is used by cdo, a widely used tool that manages netcdf files.
I have an Atom document where the atom:updated element date is that of the request made to the server. Therefore it changes on each request.
My initial thoughts were that this was incorrect and would prefer to use the date of the latest published item.
So I checked the Atom documentation for atom:updated:
The "atom:updated" element is a Date construct indicating the most recent instant in time when an entry or feed was modified in a way the publisher considers significant. Therefore, not all modifications necessarily result in a changed atom:updated value.
atomUpdated = element atom:updated { atomDateConstruct }.
Publishers MAY change the value of this element over time.
I believe this backs-up my thoughts, but maybe there is a case for using the request date in certain circumstances too.
So what date is used in atom:updated?
So what date is used in atom:updated?
The specification you cite seems to answer that question:
The "atom:updated" element is a Date construct indicating the most recent instant in time when an entry or feed was modified in a way the publisher considers significant.
As a publisher, if you consider the document to be under constant significant modification then it would be compliant with the specification to return the current time.
However, it's more likely that consumers would expect that date's change to reflect specific changes.
Im using cfspreadsheet to read data from spreadsheets inside one of my applications. I've had a great deal of difficulty dealing with date columns. If I format the cell as date english (NZ) it displays right in the spreadsheet, but when I try to upload it switched the day and month. But If I change the format to a custom "dd/mm/yyyy" format it will upload without a problem.
Why would using the default date formats within the spreadsheet mess up the format when a custom one doesn't? Is there a work around?
I was using the Date Type "*14/03/2001".
The * means that it will:
respond to changes in regional date and time settings that are specified for the operating system.
So it must have been getting turned about by java or CF somewhere along the way. I changed it to the same date mask without the asterisk and the problem stopped occurring.
I've read many a post here re: GWT date handling.
One in particular that struck a cord with me was this one
Sending a date and timezone from GAE server to GWT client
Anyhow, there's a need on a project I'm working on to be able to display days, hours, minute intervals as labels in a grid. My team has adopted an approach where all date/time instances are passed the client from the server in ISO8601 String format. The server time zone is to be respected by the client. The biz use case is that all date/time instances are in "market time", so that any browser that visits the app will see and work with dates in the "market time" timezone which happens to be GMT-05:00 (if Daylight Savings in effect) or GMT-06:00 (if Standard Time in effect).
I have posted some source on Github, here:
https://github.com/fastnsilver/gwt-datehandling-example
Particularly...
https://github.com/fastnsilver/gwt-datehandling-example/blob/master/src/main/java/me/fns/gwt/datehandling/client/util/CSTimeUtil.java
and the GWTTestCase
https://github.com/fastnsilver/gwt-datehandling-example/blob/master/src/test/java/me/fns/gwt/datehandling/client/util/CSTimeUtilTestGwt.java
in the hopes that someone can stare at the utility (and test) we're employing for date handling and help us see what we're not seeing.
EDIT
The basic problem is that CSTimeUtil#hoursInDay(Date) is not being calculated correctly in Production mode for "transition days" This method is used by other methods (like CSTimeUtil#dateToHour(Date) and CSTimeUtil#labelsForDay(Date)).
I have deployed our application with the current implementation of CSTimeUtil and it appears to work, but not quite. I'm really confused by alternate test results when e.g., mvn gwt:test is run in GWT Mode or Production Mode on Windows where the OS timezone is set to various timezones other than U.S. GMT-05:00 or GMT-06:00.
Based on some hints from Andrei and some serious blood, sweat and tears, I figured this out on my own. I have updated the code in Github, so if you're curious please go have a look there.
The basics:
Make sure all Strings are ISO8601 (no millis) compliant when sent from server to client and vice versa
Use DateTimeFormat.getFormat("yyyy-MM-ddTHH:mm:ss.SZZZZ") to format and parse dates
Retreive GMT-prefixed time zone info from java.util.Date in "Market time" using DateTimeFormat(Date, TimeZone), where TimeZone param is set as TimeZone.createTimeZone(TZ_CONSTANTS_INSTANCE.americaChicago()) and time zone String retrieved by TimeZone.getISOTimeZoneString(Date)
Generating days, see generateDay(Date, int) or hours generateHour(Date, int), from a source date had to take into consideration that an increment or decrement coudl trigger a change in time zone offset if occurring on a "transition day".
If you time zone is fixed, why would you use a string to represent date/time? You can send a standard Java Date object to the client. If you want, you can even store all dates and times as Longs and pass Longs only. You also send the GWT's TimeZone Json string for your time zone (once per session). You can find it in the GWT - there is a file with strings for all time zones.
On a client you use DateTimeFormat with many predefined formats to display whatever you need: full date, month and date, date and time, etc. Just remember to create TimeZone object from this Json string and use it in DateTimeFormat.getFormat(...).format(Date, TimeZone).
With this approach you don't have to worry about DST changes (they are encoded in that Json string) and locales. You only pass simple Date or Long objects.
I'm using GWT on the client (browser) and Joda Time on the server. I'd like to perform some DB lookups bounded by the day (i.e. 00:00:00 until 23:59:59) that a request comes in, with the time boundaries based on the user's (i.e. browser) timezone.
So I have the GWT code do a new java.util.Date() to get the time of the request, and send that to the server. Then I use Joda Time like so:
new DateTime(clientDate).toDateMidnight().toDateTime()
The trouble of course is that toDateMidnight(), in the absence of a specified TimeZone, will use the system's (i.e. the server's) TimeZone. I've been trying to find a simple way to pass the TimeZone from the browser to the server without much luck. In GWT I can get the GMT offset with:
DateTimeFormat.getFormat("Z").fmt(new Date())
which results in something like "-0400". But Joda Time's DateTimeZone.forID() wants strings formatted like "America/New_York", or an integer argument of hours and minutes. Of course I can parse "-0400" into -4 hours and 0 minutes, but I'm wondering if there is not a more straightforward way of doing this.
You could use java.util.Date's getTimezoneOffset() method. It's deprecated, but that's pretty usual for Date handling in GWT currently.
And AFAIR, you can specify something similar to "UTC+4" in Joda time.
Update: I looked it up, and it's "+04:00". Or use DateTimeZone.forOffsetHours() or even forOffsetMillis().
Gwittir (http://www.gwtsite.com) is a library for GWT that includes many cool utilities, like databinding, animation, reflection, and more. However, there are some other interesting goodies as well like the new Joda Time integration. If you have ever been frustrated by GWT’s lack of java.util.Calendar support, you’ll love this, as it makes it easy to do date manipulations in your applications.
otherwise, there are other ways to get timezone offset with + & -.
import java.util.TimeZone;
use: TimeZone.getDefault().getRawOffset()
this function will return the offset time in millisecond about your phone seeting. For Example, GMT-04:00 is equals to (-4)*60*60*1000 = -14400000.
After some operations to get the number which you want.
I have a similar but slightly different problem I think.
I actually need to store the clients timezone on the server, so that I can send out messages about dates stored in their calendar.
The dates are stored in UTC time in google app engine and of course I can store the current Timezone offset when creating the appointment. The problem comes when for instance I want to send out a summary email with a list of upcoming appointments in it. These appointments need to be offset with the correct Timezone adjustments for the client (Im happy to assume that they are still in the same timezone as when they created the appointment).
The real problem comes with Daylight Savings adjustments, so for instance I might have appointments stored for Saturday 30th October 2010 at 1pm (BST[GMT+60]) and Monday 1st November 2010 at 1pm (GMT).
So as you can imagine, I cant just use the current timezone offset (BST) as that would mean that the appointment on Monday 1st November would be listed as 2pm rather than 1pm (GMT+60)
It occurs to me that the best way to deal with this is just to store the timezone offset with each appointment individually, but I feel it would be much better to be able to determine the original timezone correctly in the first place, then just let java do the correct adjustments.