While going through an API documentation, I found that it returns date-time in the following format.
2015-03-17T13:49:31.2735318-04:00
Apart from the date part in the beginning, I could not recognize the format. What does the various fragments of the above date-time string represent? I want to parse the string to ColdFusion datetime object.
It looks like ISO 8601 format.
The part up to the letter T is the date in yyyy-mm-dd format.
The letter T separates the date and time components.
The time is HH:mm:ss followed by fractions of a second to 7 decimal places.
The -04:00 is the offset from UTC.
Related
I have dates like 54940,55001,54970 etc.
I need to convert these dates into yyyy-MM-dd format in snowflake
The following steps should help:
Convert the julian to a gregorian date with a function (the conversion depends on your understanding of a julian date - there are different ones. If you try to google that, you may find several conversion rules)
Convert the string/integer to a date by using TO_DATE() https://docs.snowflake.com/en/sql-reference/functions/to_date.html
I'm using OffsetDateTime class for parsing date from the database.
Why the date contains 'T' ??
Example: 2018-01-01T12:00:00.000Z
I can understand the format is <<Date>>T<<Time>>.<<Offset>><<TimeZone>>. But still, I don't understand why 'T' is used in between.
Thanks in advance
ISO 8601
2018-01-23T12:00:00.000Z
That means noon on the twenty-third of January in 2018 in UTC.
That is one of the standard formats defined by ISO 8601. These formats are designed for exchanging date-time values as text, easy to parse by machine, easy to read by humans across cultures. The ISO 8601 is a modern standard, supplanting formats seen in various earlier Internet standards. ISO 8601 is also being adopted in various industries beyond information technology.
The T in the middle separates the date portion from the time-of-day portion.
After the period (FULL STOP) is any number of digits for the fractional second. The standard prefers the use of COMMA, but people in the US often use the period.
The Z on the end is pronounced “Zulu” and means an offset-from-UTC of zero hours-minutes-seconds, or +00:00:00.
why 'T' is used in between
A letter was desired to avoid the use of SPACE characters to make recognition and parsing easier. As to why T, you’d have to ask the authors of the standard. I can only guess that the letter “t” was chosen for the word time in English, temps in French, etc.
The use of Z for an offset of zero is taken from common usage in aviation and military.
I highly recommend you use these ISO 8601 formats when storing, writing, exchanging, and logging date-time values as text. These formats are wisely designed to be simple and practical. They avoid the use of SPACE character, and avoid extensive use of English and any other language.
The java.time classes built into Java 8 and later use these formats by default when parsing and generating strings.
Instant.now().toString()
2019-08-27T20:15:21.005946Z
The java.time.ZonedDateTime class extends the standard wisely to append the name of the time zone in square brackets.
Instant instant = Instant.parse( "2019-08-27T20:15:21.005946Z" ) ;
ZoneId z = ZoneId.of( "Pacific/Auckland" ) ;
ZonedDateTime zdt = instant.atZone( z ) ; // Same moment, same point on the timeline, different wall-clock time.
zdt.toString(): 2019-08-28T08:15:21.005946+12:00[Pacific/Auckland]
Week
You asked:
Am I able to use 'W' instead of 'T' in my given example
No. When representing a moment, you must use a T between the date and time.
A W is used in another of the ISO 8601 formats, when representing a week date of a week-based year.
String output = zdt.toLocalDate().format( DateTimeFormatter.ISO_WEEK_DATE ;
2019-W35-3
For working with standard weeks, use the YearWeek class from the ThreeTen-Extra project that extends java.time functionality.
LocalDate ld = zdt.toLocalDate() ;
YearWeek yw = YearWeek.from( ld ) ;
ld.toString(): 2019-08-28
yw.toSting(): 2019-W35
LocalDate ld = zdt.toLocalDate() ; // Extract just the date without the time-of-day and without time zone.
See all that code above run live at IdeOne.com, except for YearWeek.
I'm creating book writing software.
The problem is, when user create story that happen say in year 200 BCE [ CE / BCE wiki], how to store this date in SQLite so I can sort it like normal DateTime.
The documentation for the built-in date functions says:
These functions only work for dates between 0000-01-01 00:00:00 and 9999-12-31 23:59:59.
However, SQLite does not have a separate data type for dates; it just uses numbers or strings, and interprets them as dates only when you apply a date function to them.
If you do not actually need to use the SQLite date functions, you can use any type and format, as long as it sorts correctly.
Strings like yyyy-mm-dd do not sort correctly for BCE dates, so you have to use numbers (Julian days, or Unix timestamps, or any other format).
Is there a way I can format this String for example "2014-08-22T18:30:00Z" to 2 substrings like 2014-08-22 and 18:30?
I'd suggest that you do not want to consider these two different strings. I'd suggest the real question is how to convert this ISO 8601 / RFC 3339 date string into a NSDate. And then you can create separate strings for the date and time if you want.
But you probably want to convert them into a single NSDate object, because that original string is in Zulu (i.e. GMT/UTC), but you may want to show the final date and time in the local time zone. But if you return them as separate strings, when you do time zone adjustment, it becomes a hassle to correct the date when the time zone change results in a different day of the year.
Anyway, this is how to parse the "2014-08-22T18:30:00Z" string:
let formatter = NSDateFormatter()
formatter.dateFormat = "yyyy-MM-dd'T'HH:mm:ssZ"
formatter.locale = NSLocale(localeIdentifier: "en_US_POSIX")
let date = formatter.dateFromString("2014-08-22T18:30:00Z")
Note, the locale issue is a subtle one that many people overlook and discussed in Technical Q&A QA1480.
I kind of assumed it was a string, so I compared it as a string, but not surprisingly it failed. I believe thats how it works in Mysql. I could be wrong as I haven't worked on it in a while. In either case, how can I check if dates are equal in SQLite? I will be using it in a WHERE clause.
SELECT a._id, b._id, b.start_date,a.event_name, b.start_time,
b.end_date, b.end_time, b.location FROM events_info b INNER JOIN events a ON
a._id=b.event_id WHERE b.start_time = '6:00';
(added space to make it easier to look at)
SQLite doesn't have a dedicated DATETIME type. Normally what people do is make sure they store the date as a formatted string that is consistent; for example, YYYY-MM-DD hh:mm:ss. If you do so, as long as you're consistent, then you can compare dates directly:
SELECT * FROM a WHERE q_date < '2013-01-01 00:00:00';
This works because even though the comparison is technically an alphabetical comparison and not a numeric one, dates in a consistent format like this sort alphabetically as well as numerically.
For such a schema, I would suggest storing dates in 24-hour format (the above example is midnight). Pad months, days, and hours with zeros. If your dates will span multiple timezones, store them all in UTC and do whatever conversion you need client-side to convert them to the local time zone.
Normally dates and times are stored all in one column. If you have to have them separated for whatever reason, just make sure you dates are all consistent and your times are all consistent. For example, dates should all be YYYY-MM-DD and times should all be hh:mm:ss.
The reason that YYYY-MM-DD hh:mm:ss is the preferred format is because when you go from the largest date interval (years) to the smallest (seconds), you can index and sort them very easily and with high performance.
SELECT * FROM a WHERE q_date = '2012-06-04 05:06:00';
would use the index to hone in on the date/time instead of having to do a full table scan. Or if they're in two separate rows:
SELECT * FROM a WHERE q_date = '2012-06-04' AND q_time = '05:06:00';
The key is to make sure that the dates and times are in a consistent format going into the database. For user-friendly presentation, do all conversion client-side, not in the database. (For example, convert '2012-06-04 05:06:00' to "1:06am Eastern 6/4/2012".)
If this doesn't answer question, could you please post the exact format that you're using to store your dates and times, and two example dates that you're trying to compare that aren't working the way you expect them to?
Sqlite can not compare dates directly. we need to convert them in seconds as well as integer also.
Example
SELECT * FROM Table
WHERE
CAST(strftime('%s', date_field) AS integer) <=CAST(strftime('%s', '2015-01-01') AS integer) ;
From Datatypes In SQLite Version 3:
1.2 Date and Time Datatype
SQLite does not have a storage class set aside for storing dates and/or times. Instead, the built-in Date And Time Functions of SQLite are capable of storing dates and times as TEXT, REAL, or INTEGER values:
TEXT as ISO8601 strings ("YYYY-MM-DD HH:MM:SS.SSS").
REAL as Julian day numbers, the number of days since noon in Greenwich on November 24, 4714 B.C. according to the proleptic Gregorian calendar.
INTEGER as Unix Time, the number of seconds since 1970-01-01 00:00:00 UTC.
Applications can chose to store dates and times in any of these formats and freely convert between formats using the built-in date and time functions.
If you look at the examples in Date And Time Functions, something like this should get you close to what you want (which, I'm assuming, is 6:00 of the current day):
WHERE b.start_time = date('now', 'start of day', '+6 hours')