I live in Hungary and I want to create gwt programs.
timestamp
1324565400
gwt html
<meta name="gwt:property" content="locale=hu_HU">
my code
DateTimeFormat dateFormater = DateTimeFormat.getFormat("H:mm");
...
mikorColumnConfig.setRenderer(new GridCellRenderer<RendelesIdeiglenes>() {
#Override
public Object render(
RendelesIdeiglenes model, String property,
ColumnData config, int rowIndex, int colIndex,
ListStore<RendelesIdeiglenes> store,
Grid<RendelesIdeiglenes> grid)
{
return dateFormater.format((Date) model.get(property));
}
});
and gwt displays
15:50
but the real time is
14:50
Why does it display the wrong time? I belive it could have something to do with the day light saving time, how do I activate the dayLightSaving setting?
Hmm, well, 1324565400000 is 14:50 UTC, and 15:50 UTC+1, and I believe Hungary is in UTC+1, so, living in Hungary, your computer is in UTC+1, and thus expectedly displays 15:50.
Note: the app's locale (as set with the meta name="gwt:property") doesn't change the time-zone that applies. That one is always the one of the computer running the code, i.e. dates are always local dates, and are formatted as such unless you pass an explicit TimeZone to the format method.
BTW, you might want to use DateTimeFormat.getFormat(PredefinedFormat.TIME_SHORT) rather than DateTimeFormat.getFormat("H:mm"). The short time format in the hu locale is H:mm so you won't notice a change, but it'll be easier to internationalize it later on (if you add English support, you'll automatically use the appropriate short time format for the locale, contrary to H:mm which is fixed and locale independent).
Related
In the "Activity for jobs' page in Rundeck the execution time has a relative time field (example: "Today at 10:15 AM" or "Last Sunday at 4:51 AM") after the timestamp.
It is easy to change the date format of the timestamp by adding jobslist...format[.ko] in the i18n/messages.properties file.
It seems impossible however to change the format of the relative time message. It seems to be hard-coded in en_US with AM/PM which doesn't look too good in in non-English-speaking countries. The format is always the same regardless of the ?lang=xx parameter or the default language in the browser. Interestingly, other objects (like hovering over the field with the mouse and the duration get translated).
Has anyone successfully changed this?
Example. See the duration field
I have been trying this with the docker images (4.8.0, 4.9.0 and SNAPSHOT)
I've looked at the source code and apparently this lies somewhere in the moment.js code.
In some parts, the date formats are hard coded as you say, please add your use case on this thread.
I was importing internationalization for my app but I have a problem where I parse my String but it only returns the date and not the time. When I change the phone language, my format for the Date changes but my Time isn't showing.
This is when it is EN_US
This is when it is EU(German)
That works well but my time format is missing...
This is the default String from the API:
Here is the code:
/// I set a variable that calls the locale of the phone language and changes according to the phone preference
final f = DateFormat.yMd(Localizations.localeOf(context).languageCode);
/// where I dispay time and date but only date is shown in the pictures above
Text('Time and date: ${f.format(DateTime.parse(apicall.dateCreated))}');
My questions are: How do I show the time and how can I swap between showing the Time first then the Date, and opposite, if I want to show the Date first then the Time? (example 18-May-21 11:10h and if I want to do this 11:10h 18-May-21)
Thanks in advance for the help!
I suppose you should use DateFormat.jm().add_yMd(): this will show time first and then date. To swap it just use DateFormat.yMd().add_jm()
More info here
If I have a TimeZone, the string property currently produces the time zone in ISO-8601 format.
import ceylon.time.timezone {
OffsetTimeZone
}
shared void run() {
value timezone = OffsetTimeZone(27000000);
print(timezone.string); // +07:30
}
Is there a way to get it in other formats, specifically without the colon (e.g. +0730)? (I mean, other than dropping the fourth character.) The ceylon.time.timezone.timeZone.parse function accepts offsets in this format, but I cannot figure out how to get them back.
There’s more detailed formatting support in ceylon.locale module. See Formats type documentation.
Well, to be completely honest, it doesn’t give you a detailed formatting options that one might be used to when formatting dates in Java. You have basically just choices of short, medium and long date format and not much more.
I get the following datetime String from a backend system: 2014-06-10+02:00.
Is this a valid datetime? There is no information about the time (I get only the date) but there is a time offset.
If it is valid according to which standard is this valid and what is the UTC time?
Thanks a lot
This is a valid date, not a date-time.
An offset-from-UTC is relevant to a date. For any given moment the date varies around the globe by time zone. For example, a few minutes after midnight in Paris France is a new day while still “yesterday” in Montréal Québec.
By the way, an offset-from-UTC is not a time zone. A time zone is a history of changes (past, present, and future) to the offset used by a particular region. A time zone has a name in format of continent/region such as America/Montreal.
With a date and an offset, you can determine the range of all moments occurring in that day, all the points on the timeline.
Example code in Java.
ZoneOffset offset = ZoneOffset.parse( "+02:00" );
LocalDate ld = LocalDate.parse( "2014-06-10" ) ;
OffsetDateTime odt = OffsetDateTime.of( ld , LocalTime.MIN , offset );
https://docs.oracle.com/javase/8/docs/api/java/time/format/DateTimeFormatter.html
The output is valid Date but not a valid Time as per ISO Date Specification. Please see ISO_OFFSET_DATE.
UTC (Coordinated Universal Time) is a time standard is defined by International Telecommunications Union.
If it is valid according to which standard is this valid and what is
the UTC time?
You have asked three questions in this line and the answer to these questions are as follows:
Is it valid?
Yes, it is a valid date string.
You have already mentioned in your question that it does not have a time part; rather, it has a (timezone) offset of +02:00 hours. So, it is just a valid date string, not a date-time string.
Which standard is this?
This is ISO 8601.
What is the UTC time?
A date starts with the start-of-the-day time which, in most cases, is 00:00 hours. However, for the timezones that observe DST, it may not be the case. Such timezones have generally one hour difference in the timezone offset between with and without DST.
Your string has a fixed (timezone) offset (+02:00); rather than a timezone itself (e.g. Africa/Cairo) and therefore, in this case, the start of the day is always 00:00 hours.
So, it can be written as 2014-06-10'T'00:00:00+02:00. As soon as you represent it in this way, I am sure you must have already guessed that it is equivalent to 2014-06-09'T'22:00:00Z where Z is the timezone designator for zero-timezone offset. It stands for Zulu and specifies the Etc/UTC timezone (which has the timezone offset of +00:00 hours).
Enough talking, let's write some code.
import java.time.OffsetDateTime;
import java.time.ZoneOffset;
import java.time.format.DateTimeFormatter;
import java.time.format.DateTimeFormatterBuilder;
import java.time.temporal.ChronoField;
import java.util.Locale;
public class Main {
public static void main(String[] args) {
String str = "2014-06-10+02:00";
DateTimeFormatter dtf = new DateTimeFormatterBuilder()
.appendPattern("u-M-d['T'[H[:m[:s]]]]XXX")
.parseDefaulting(ChronoField.HOUR_OF_DAY, 0)
.parseDefaulting(ChronoField.MINUTE_OF_HOUR, 0)
.parseDefaulting(ChronoField.SECOND_OF_MINUTE, 0)
.toFormatter(Locale.ENGLISH);
OffsetDateTime odt = OffsetDateTime.parse(str, dtf);
System.out.println(odt);
OffsetDateTime odtUtc = odt.withOffsetSameInstant(ZoneOffset.UTC);
// The default format omits second and fraction-of-second if they are zero
System.out.println(odtUtc);
// Custom format
DateTimeFormatter formatter = DateTimeFormatter.ofPattern("uuuu-MM-dd'T'HH:mm:ssXXX", Locale.ENGLISH);
System.out.println(formatter.format(odtUtc));
}
}
Output:
2014-06-10T00:00+02:00
2014-06-09T22:00Z
2014-06-09T22:00:00Z
Learn more about the the modern date-time API* from Trail: Date Time.
* For any reason, if you have to stick to Java 6 or Java 7, you can use ThreeTen-Backport which backports most of the java.time functionality to Java 6 & 7. If you are working for an Android project and your Android API level is still not compliant with Java-8, check Java 8+ APIs available through desugaring and How to use ThreeTenABP in Android Project.
yes it is correct date format.There are lot of place jerusalam..etc with the +2 hour you can find it in your system.
Was using the below tag for displaying the timezone which was working fine until now when the daylight saving has happened and as our server is in UK displaying the time as 01/04/2015 03:43:00 PM + 0100, we would also like to have the timezone displayed, please advice.
Tag Used Previously:
date:format-date(date:date-time(), 'dd/MM/yyyy hh:mm:ss a Z')
Regards
Arvind
If by "properly" you mean you want it displayed as "BST" (for British Summer Time) then there isn't actually enough information in the date/time value to do this - a time-zone offset of +1 occurs in many different timezones near the Greenwich meridian.
You're using the EXSLT library for formatting dates and times. This is based on Java's SimpleDateFormat class, so you could try your luck with the timezone designator z instead of Z.
Alternatively, if you've got access to XSLT 2.0, you can use the format-dateTime() function. This suffers from the same problem (the dateTime value only stores an offset, which doesn't actually tell you the name of the timezone). But you can give the processor a clue by setting the 5th argument of format-dateTime() to "Europe/London", in which case it might be able to work it out.