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.
Related
I have been looking at the above question and have most of it correct.
I am going to get a datetime in Zulu, and then will want to output that format.
My first go is just as simple as:
DateFormat format = new DateFormat("yyyy-MM-dd'T'HH:mm:ss.SSS'Z'");
My issue I am having is the T and Z. Obviously T is used to separate the date from the time and the Z is representative of Zulu time.
That being said the users will be entering a datetime in Zulu, so it wont need to be converted from Local to Zulu, so i was not sure if 'Z' is an acceptable result. I was not sure if there is a different want to handle this, or if my result was the best answer.
Try this package, Jiffy.
String isoFomart = Jiffy().format(); // This will return ISO format from now
You can also add your DateTime object
String isoFomart = Jiffy(DateTime.now()).format(); // This will also return ISO format from now
Hope this helped
The DateTime object has a method called: toIso8601String which is used to return an ISO formatted string. The 'Z' will be added if isUTC is true, otherwise the result will not have the Z in it.
Make sure that the DateTime object itself is correctly set to UTC as if you look in the constructor for the class will tell you a lot of the defaults are local with the exception of the DateTime.utc() static function.
In that concept, you dont really need a DateFormat use to define an iso string.
I'm currently working with embarcadero c++, this is the first time I'm working with it so it's completely new to me.
What I'm trying to achieve is to get the current date, make sure the date has the "dd/MM/yyyy" format. When I'm sure this is the case I want to add a month to the current date.
So let's say the current date is 08/18/2016 this has to be changed to 18/08/2016 and then the end result should be 18/09/2016.
I've found that there is a method for this in embarcardero however I'm not sure how to use this.
currently I've only been able to get the current date like this.
TDateTime currentDate = Date();
I hope someone will be able to help me out here.
I figured it out.
After I've searched some more I found the way to use the IncMonth method on this page.
The example given my problem is as follows:
void __fastcall TForm1::edtMonthsExit(TObject *Sender)
{
TDateTime StartDate = edtStartDate->Text;
int Months = edtMonths->Text.ToInt();
TDateTime NextPeriod = IncMonth(StartDate, Months);
edtNextPeriod->Text = NextPeriod;
}
After looking at I changed my code accordingly to this
TDateTime CurrentDate = Date();
TDateTime EndDate = IncMonth(CurrentDate, 1);
A date object doesn't have a format like "dd/MM/yyyy". A date object is internally simply represented as a number (or possibly some other form of representation that really isn't your problem or responsibility).
So you don't have to check if it's in this format because no date objects will ever be in this format, they simply don't have a format.
You will have to do additions/subtractions on the Date object that the language or library gives you, THEN (optionally) you can format it to a human-readable string so it looks like 18/08/2016 or 18th of August 2016 or whatever other readable format that you choose.
It might be that the TRANSFER of a date between 2 systems is in a similar format, but then formatting the date like that is entirely up to you.
As for how to do that, the link you posted seems like a possible way (or alternatively http://docwiki.embarcadero.com/Libraries/Berlin/en/System.SysUtils.IncMonth), I'm afraid I can't give you an example as I'm not familiar with the tool/language involved, I'm just speaking generically about Date manipulations and they should ALWAYS be on the raw object.
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.
I'm working on an app that allows the user to edit several dates in a form. The dates are rendered in the European format (DD-MM-YYYY) while the databases uses the default YYYY-MM-DD format.
There are several ways to encode/decode this data back and forth from the database to the user, but they all require a lot of code:
Use a helper function to convert the date before saving and after retrieving (very cumbersome, requires much code)
Create a separate attribute for each date attribute, and use the setNameAttribute and getNameAttribute methods to decode/encode (also cumbersome and ugly, requires extra translations/rules for each attribute)
Use JavaScript to convert the dates when loading and submitting the form (not very reliable)
So what's the most efficient way to store, retrieve and validate dates and times from the user?
At some point, you have to convert the date from the view format to the database format. As you mentioned, there are a number of places to do this, basically choosing between the back-end or the front-end.
I do the conversion at the client side (front-end) using javascript (you can use http://momentjs.com to help with this). The reason is that you may need different formats depending on the locale the client is using (set in the browser or in his profile preferences for example). Doing the format conversion in the front-end allows you to convert to these different date formats easily.
Another advantage is that you can then use the protected $dates property in your model to have Laravel handle (get and set) these dates automatically as a Carbon object, without the need for you to do this (see https://github.com/laravel/framework/blob/master/src/Illuminate/Database/Eloquent/Model.php#L126).
As for validation, you need can then use Laravel's built-in validation rules for dates, like this:
'date' => 'required|date|date_format:Y-n-j'
While client-side is good for UX, it doesn't let you be sure, all will be good.
At some point you will need server-side validation/convertion anyway.
But here's the thing, it's as easy as this:
// after making sure it's valid date in your format
// $dateInput = '21-02-2014'
$dateLocale = DateTime::createFromFormat('d-m-Y', $dateInput);
// or providing users timezone
$dateLocale =
DateTime::createFromFormat('d-m-Y', $dateInput, new DateTime('Europe/London'));
$dateToSave = $dateLocale
// ->setTimeZone(new TimeZone('UTC')) if necessary
->format('Y-m-d');
et voila!
Obviously, you can use brilliant Carbon to make it even easier:
$dateToSave = Carbon::createFromFormat('d-m-Y', $dateInput, 'Europe/London')
->tz('UTC')
->toDateString(); // '2014-02-21'
Validation
You say that Carbon throws exception if provided with wrong input. Of course, but here's what you need to validate the date:
'regex:/\d{1,2}-\d{1,2}-\d{4}/|date_format:d-m-Y'
// accepts 1-2-2014, 01-02-2014
// doesn't accept 01-02-14
This regex part is necessary, if you wish to make sure year part is 4digit, since PHP would consider date 01-02-14 valid, despite using Y format character (making year = 0014).
The best way I found is overriding the fromDateTime from Eloquent.
class ExtendedEloquent extends Eloquent {
public function fromDateTime($value)
{
// If the value is in simple day, month, year format, we will format it using that setup.
// To keep using Eloquent's original fromDateTime method, we'll convert the date to timestamp,
// because Eloquent already handle timestamp.
if (preg_match('/^(\d{2})\/(\d{2})\/(\d{4})$/', $value)) {
$value = Carbon\Carbon::createFromFormat('d/m/Y', $value)
->startOfDay()
->getTimestamp();
}
return parent::fromDateTime($value);
}
}
I'm new in PHP, so I don't know if it's the best approach.
Hope it helps.
Edit:
Of course, remember to set all your dates properties in dates inside your model. eg:
protected $dates = array('IssueDate', 'SomeDate');
I am in the unfortunate position that I need to use a composite id in a Grails app where I work with legacy data. This means I have to override some actions in the controller, but as I did this I was struck by the fact that I could not use use a date argument directly as a parameter to a dynamic method.
Instead of just doing MyLegacyObj.findBySystemIdAndLogDate(params.systemId, params.logDate), I first needed to parse the date string before giving it to the dynamic method. To further complicate matters I had no idea what format the date string had (until I added lots of log.debug() string to the output). So now I have a bit of code looking like this
def formatter = new SimpleDateFormat("EEE MMM d HH:mm:ss z yyyy")
MyLegacyObj.findBySystemIdAndLogDate(params.systemId, formatter.parse(params.logDate));
This feels unoptimal, no to say dangerous (what if the date format changes with the locale?)? What would be a recommended way of doing this, and do I really need to parse dates at all?
Date is a pretty complex object and params are just Strings, so Date is submitted in parts. It is "magically" assembled from the parts when assigning x.properties = params.
Command object will do the work for you, if you add a Date field to it.
It has nothing to do with methods' dynamic or static invocation. Your GSP that renders Date editor might interfere too.