Migrating Joda time to Java 8
Joda:
UserObject user = new UserObject()
user.setCreatedAt(new DateTime(rs.getTimestamp("columnName")));`
Migrating to Java 8
This is my code; it does compile; I am doubtful if it works:
ZonedDateTime.ofInstant(rs.getTimestamp("columnName").toLocalDateTime().toInstant(ZoneOffset.UTC),ZoneId.of("UTC")));
In some cases, the date is wrong. Any advice?
tl;dr
To track a moment in history, use Instant as the type of your class member variable. Specifically, this moment is seen as a date and time-of-day in UTC.
public class UserObject() {
Instant createdAt ;
…
public void setCreatedAt( Instant instantArg ) {
this.createdAt = instantArg ;
{
}
Usage, capturing the current moment.
UserObject user = new UserObject() ;
user.setCreatedAt( Instant.now() ) ;
Usage, populating value from database.
UserObject user = new UserObject() ;
Instant instant = myResultSet.getObject( "when_created" , Instant.class ) ;
user.setCreatedAt( instant ) ;
JDBC 4.2 does not require support for Instant (a moment in UTC). If your driver does not support that class, switch to OffsetDateTime which is required.
UserObject user = new UserObject() ;
OffsetDateTime odt = myResultSet.getObject( "when_created" , OffsetDateTime.class ) ;
user.setCreatedAt( odt.toInstant() ) ; // Convert from an `OffsetDateTime` (for any offset-from-UTC) to `Instant` (always in UTC).
Present to the user, localized for the user-interface.
user // Your business object.
.getCreatedAt() // Returns a `Instant` object.
.atZone( // Adjust from UTC to a time zone. Same moment, same point on the timeline, different wall-clock time.
ZoneId.of( "Pacific/Auckland" ) // Specify the user’s desired/expected time zone.
) // Returns a `ZonedDateTime` object.
.format( // Generate a `String` representing the value of date-time object.
DateTimeFormatter.ofLocalizedDateTime(
FormatStyle.FULL // Specify how long or abbreviated the string.
)
.withLocale( // Specify `Locale` to determine human language and cultural norms for localization.
Locale.CANADA_FRENCH
)
) // Returns a `String`.
Notice that Locale has nothing to do with time zone, an orthogonal issue. The code above might be for a business person from Québec who is traveling in New Zealand. She wants to see the wall-clock time used by the kiwis around her, but she prefers to read its textual display in her native French. Both time zone and locale are issues best left to presentation only; generally best to use UTC in the rest of your code. Thus, we defined our member variable createdAt as an Instant, with Instant always being in UTC by definition.
Avoid java.sql.Timestamp
The java.sql.Timestamp, along with java.sql.Date, java.util.Date, and Calendar are all part of the terribly troublesome old date-time classes that were supplanted years ago by the java.time classes.
Joda-Time too is now supplanted by the java.time classes, as stated in the front page of the project’s site.
java.time
As of JDBC 4.2 and later, we can directly exchange java.time objects with the database.
Instant
Send the current moment to the database using Instant class. The Instant class represents a moment on the timeline in UTC with a resolution of nanoseconds (up to nine (9) digits of a decimal fraction).
Instant instant = Instant.now() ; // Capture the current moment in UTC.
myPreparedStatement.setObject( … , instant ) ;
And retrieval.
Instant instant = myResultSet.getObject( … , Instant.class ) ;
ZonedDateTime
To see that same moment through the lens of the wall-clock time used by the people of a particular region (a time zone), apply a ZoneId to get a ZonedDateTime.
ZoneId z = ZoneId.of( "Africa/Tunis" ) ;
ZonedDateTime zdt = instant.atZone( z ) ;
LocalDateTime is not a moment
.toLocalDateTime().
Never involve LocalDateTime class when representing a specific moment in time. The class purposely lacks any concept of time zone or offset-from-UTC. As such, it cannot represent a moment, is not a point on the timeline. It is a vague idea about potential moments along a range of about 26-27 hours (the range of time zones).
About java.time
The java.time framework is built into Java 8 and later. These classes supplant the troublesome old legacy date-time classes such as java.util.Date, Calendar, & SimpleDateFormat.
To learn more, see the Oracle Tutorial. And search Stack Overflow for many examples and explanations. Specification is JSR 310.
The Joda-Time project, now in maintenance mode, advises migration to the java.time classes.
You may exchange java.time objects directly with your database. Use a JDBC driver compliant with JDBC 4.2 or later. No need for strings, no need for java.sql.* classes. Hibernate 5 & JPA 2.2 support java.time.
Where to obtain the java.time classes?
Java SE 8, Java SE 9, Java SE 10, Java SE 11, and later - Part of the standard Java API with a bundled implementation.
Java 9 brought some minor features and fixes.
Java SE 6 and Java SE 7
Most of the java.time functionality is back-ported to Java 6 & 7 in ThreeTen-Backport.
Android
Later versions of Android (26+) bundle implementations of the java.time classes.
For earlier Android (<26), a process known as API desugaring brings a subset of the java.time functionality not originally built into Android.
If the desugaring does not offer what you need, the ThreeTenABP project adapts ThreeTen-Backport (mentioned above) to Android. See How to use ThreeTenABP….
This seems to work:-
ZonedDateTime.ofInstant(rs.getTimestamp("columnname").toInstant(), ZoneId.of("UTC"))
Use the following:
rs.getTimestamp("columnName").toInstant()
.atZone(ZoneId.[appropriate-zone-ID-here])
You need to use a ZoneId appropriate to the region (you may try with ZoneId.systemDefault() for a start).
For more details about the differences between various Java-Time APIs, see this great answer.
Related
I have a date in the string format
String date = "2021-04-26 08:28:56 "
Now, I want to consider this as an EST Date and convert it into UTC.
The UTC for this would be
"2021-04-25 10:58:56"
So,
Input :
2021-04-26 08:28:56
Output :
2021-04-25 10:58:56
How can I do this in Java ?
tl;dr
LocalDateTime
.parse(
"2021-04-26 08:28:56"
.replace( " " , "T" )
)
.atZone(
ZoneId.of( "America/New_York" )
)
.toInstant()
.toString()
.replace( "T" , " " )
.replace( "Z" , "" )
See this code run live at IdeOne.com.
2021-04-26 12:28:56
Your expected result is incorrect. If by EST you meant a time zone such as America/New_York, that zone at that moment is four hours behind UTC. So to get from 8 AM you must add 4 hours, to get 12 noon rather than your expected 10 AM hour on the previous date.
Details
Parse your input as a LocalDateTime because it lacks an indicator of time zone or offset-from-UTC. We convert your input to comply with ISO 8601 by replacing the SPACE in the middle with a T.
A LocalDateTime does not represent a moment, is not a point on the timeline. This class represents only a date and time-of-day. Without the context of a time zone or offset-from-UTC, we do not know what clock where strikes that time.
You claim to know this string was intended to represent a date-time as seen in EST. Unfortunately, EST is not a real time zone name. Did you mean east coast time of North America, such as America/New_York? If so, your expected output is incorrect.
If so, obtain a ZoneId for that time zone. Apply the time zone to get a ZonedDateTime. Now we have defined a moment, a specific point on the timeline.
You want to see the same moment in UTC. One easy way to adjust to UTC is to simply extract an Instant from our ZonedDateTime object. An Instant object is always in UTC, by definition.
Your desired output is similar to the standard ISO 8601 format used by default in the toString method of Instant. Just remove the T from between the date and the time-of-day, and remove the Z at the end that represents an offset of zero hours-minutes-seconds. By the way, I suggest not removing the Z to make the meaning crystal clear. Removing the Z introduces ambiguity.
String input = "2021-04-26 08:28:56".replace( " " , "T" ) ;
LocalDateTime ldt = LocalDateTime.parse( input ) ;
ZoneId z = ZoneId.of( "America/New_York" ) ;
ZonedDateTime zdt = ldt.atZone( z ) ;
Instant instant = zdt.toInstant() ; // Adjust to UTC by extracting an `Instant` object. `Instant` is always in UTC, by definition.
String output = instant.toString().replace( "T" , " " ).replace( "Z" , "" ) ;
About java.time
The java.time framework is built into Java 8 and later. These classes supplant the troublesome old legacy date-time classes such as java.util.Date, Calendar, & SimpleDateFormat.
To learn more, see the Oracle Tutorial. And search Stack Overflow for many examples and explanations. Specification is JSR 310.
The Joda-Time project, now in maintenance mode, advises migration to the java.time classes.
You may exchange java.time objects directly with your database. Use a JDBC driver compliant with JDBC 4.2 or later. No need for strings, no need for java.sql.* classes. Hibernate 5 & JPA 2.2 support java.time.
Where to obtain the java.time classes?
Java SE 8, Java SE 9, Java SE 10, Java SE 11, and later - Part of the standard Java API with a bundled implementation.
Java 9 brought some minor features and fixes.
Java SE 6 and Java SE 7
Most of the java.time functionality is back-ported to Java 6 & 7 in ThreeTen-Backport.
Android
Later versions of Android (26+) bundle implementations of the java.time classes.
For earlier Android (<26), the process of API desugaring brings a subset of the java.time functionality not originally built into Android.
If the desugaring does not offer what you need, the ThreeTenABP project adapts ThreeTen-Backport (mentioned above) to Android. See How to use ThreeTenABP….
I'm trying to get a date from a DataObject (Service Date Object (SDO)) that comes to me as an input and insert it into an Oracle database. The problem has been that the Date I get does not seem to have the introduced hour.
I am using the setDate() method from DataObject with the following value: 2019-05-22T13:30:00Z.
For some reason, when using getDate() what is returning is the day entered with the hour set at 0 (2019-05-22 00:00:00).
I'm not sure if it's due to the input format or something related to the Date class from java.utils.
An easy solution would be to pass it as String and convert it into Date using a format but I would like to save this intermediate step.
java.util.Date versus java.sql.Date
Your Question does not provide enough detail to know for sure, but I can take an educated guess.
returning is the day entered with the hour set at 0 (2019-05-22 00:00:00).
I suspect your code calling setDate and/or getDate is using a java.sql.Date object rather than a java.util.Date object.
➥ Check your import statements. If you used the wrong class by accident, that would explain the time-of-day getting set to 00:00.
java.util.Date represents a moment in UTC (a date, a time-of-day, and an offset-from-UTC of zero hours-minutes-seconds).
java.sql.Date pretends to represent a date-only, without a time-of-day and without a time zone or offset-from-UTC. Actually does contain a time-of-day and offset, but tries to adjust the time to 00:00:00.0 as part of the pretense.
Confusing? Yes. These old date-time classes from the earliest days of Java are a bloody awful mess, built by people who did not understand the complexities of date-time handling. Avoid these legacy date-time classes!
These legacy classes were supplanted years ago by the modern java.time classes defined in JSR 310. Try to do all your work in java.time. When interoperating with old code such as SDO that is not yet updated for java.time, call on new conversion methods added to the old classes.
The modern replacement of a java.util.Date is java.time.Instant. Both represents a moment in UTC, though Instant has a finer resolution of nanoseconds versus milliseconds.
Instant instant = Instant.now() ; // Capture the current moment in UTC.
Convert from modern class to legacy class. Beware of data-loss: Any microseconds or nanoseconds in the fractional second are truncated to milliseconds (as noted above).
java.util.Date d = java.util.Date.from( instant ) ; // Convert from modern to legacy. Truncates any microseconds or nanoseconds.
Pass to your SDO object.
mySdoDataObject.setDate( d ) ;
Going the other direction, retrieve the legacy java.util.Date object and immediately convert to an Instant.
Instant instant = mySdoDataObject.getDate().toInstant() ;
To see that same moment through the wall-clock time used by the people of a particular region (a time zone), apply a ZoneId to get a ZonedDateTime object.
ZoneId z = ZoneId.of( "America/Montreal" ) ;
ZonedDateTime zdt = instant.atZone( z ) ; // Same moment, same point on the timeline, different wall-clock time.
An easy solution would be to pass it as String
No! Use smart objects, not dumb strings. We have the industry-leading date-time library built into Java, so use it.
Database
As of JDBC 4.2, we can directly exchange java.time objects with the database.
Your JDBC driver may optionally handle Instant. If not, convert to OffsetDateTime.
OffsetDateTime odt = instant.atOffset( ZoneOffset.UTC ) ;
myPreparedStatement.setObject( … , odt ) ;
Retrieval.
OffsetDateTime odt = myResultSet.getObject( … , OffsetDateTime.class ) ;
Instant instant = odt.toInstant() ;
About java.time
The java.time framework is built into Java 8 and later. These classes supplant the troublesome old legacy date-time classes such as java.util.Date, Calendar, & SimpleDateFormat.
To learn more, see the Oracle Tutorial. And search Stack Overflow for many examples and explanations. Specification is JSR 310.
The Joda-Time project, now in maintenance mode, advises migration to the java.time classes.
You may exchange java.time objects directly with your database. Use a JDBC driver compliant with JDBC 4.2 or later. No need for strings, no need for java.sql.* classes.
Where to obtain the java.time classes?
Java SE 8, Java SE 9, Java SE 10, Java SE 11, and later - Part of the standard Java API with a bundled implementation.
Java 9 adds some minor features and fixes.
Java SE 6 and Java SE 7
Most of the java.time functionality is back-ported to Java 6 & 7 in ThreeTen-Backport.
Android
Later versions of Android bundle implementations of the java.time classes.
For earlier Android (<26), the ThreeTenABP project adapts ThreeTen-Backport (mentioned above). See How to use ThreeTenABP….
The ThreeTen-Extra project extends java.time with additional classes. This project is a proving ground for possible future additions to java.time. You may find some useful classes here such as Interval, YearWeek, YearQuarter, and more.
how to mock following code? i dont want to change my code.
Date date = new Date();
String res_timestamp=new Timestamp(date.getTime()).toString();
my code:
SimpleDateFormat sdf = new SimpleDateFormat("yyyy-MM-dd HH:mm:ss");
sdf.setTimeZone(TimeZone.getTimeZone("PST"));
Date NOW = sdf.parse("2019-02-11 00:00:00");
Timestamp time=new Timestamp(NOW.getTime());
whenNew(Timestamp.class).withNoArguments().thenReturn(time);
how can i mock it? am finding hard to mock it.
how can i solve it?
note: i do not want to change my code. without changing my code i have to mock those two lines.
tl;dr
Use java.time.Clock, ZonedDateTime, Instant, ZoneId.
Inject an altered Clock object as a dependency: Clock.fixed( … ).
Never use Date, Calendar, SimpleDateFormat, Timestamp, TimeZone.
Pass an altered Clock object as a dependency
You are using terrible date-time classes that were supplanted years ago by the java.time classes defined by JSR 310.
The java.time.Clock class offers several alternate behaviors suitable for testing. These included a fixed point in time, altered cadences, and and adjustment from the current moment.
Pass one of these Clock objects to the various methods in the java.time classes for your testing purposes.
PST is not a time zone. Specify a proper time zone name in the format of Continent/Region, such as America/Montreal, Africa/Casablanca, or Pacific/Auckland. Never use the 2-4 letter abbreviation such as EST or IST as they are not true time zones, not standardized, and not even unique(!).
ZoneId z = ZoneId.of( "America/Los_Angeles" ) ;
Build up the specific moment you have in mind for your testing.
LocalDate ld = LocalDate.of( 2019 , 2 , 11 ) ;
LocalTime lt = LocalTime.MIN ;
ZonedDateTime zdt = ZonedDateTime.of( ld , lt , z ) ;
zdt.toString(): 2019-02-11T00:00-08:00[America/Los_Angeles]
Calling Clock.fixed requires an Instant, a moment in UTC. We can adjust from our zoned value to UTC by extracting an Instant. Same moment, same point on the timeline, different wall-clock time.
Instant instant = zdt.toInstant() ;
instant.toString(): 2019-02-11T08:00:00Z
Specify a Clock that forever reports the current moment as that specific moment, without incrementing.
Clock clock = Clock.fixed( instant , z ) ;
clock.toString(): FixedClock[2019-02-11T08:00:00Z,America/Los_Angeles]
Inject the fixed clock as a dependency.
Instant now = Instant.now( clock ) ; // Tell me a lie.
now.toString(): 2019-02-11T08:00:00Z
See this code run live at IdeOne.com.
JDBC 4.2
If you were instantiating java.sql.Timestamp for use with a database, instead use the java.time classes. As of JDBC 4.2, we can exchange java.time objects with a database.
Your JDBC driver might have optional support for Instant.
myPreparedStatement.setObject( … , instant ) ; // Storing data.
Instant instant = myResultSet.get( … , Instant.class ) ; // Retrieving data.
Your driver must support OffsetDateTime.
myPreparedStatement.setObject( … , instant.atOffset( ZoneOffset.UTC ) ) ; // Storing data.
OffsetDateTime odt = myResultSet.get( … , OffsetDateTime.class ) ; // Retrieving data.
Adjust into a time zone.
ZonedDateTime zdt = odt.atZoneSameInstant( z ) ;
About java.time
The java.time framework is built into Java 8 and later. These classes supplant the troublesome old legacy date-time classes such as java.util.Date, Calendar, & SimpleDateFormat.
The Joda-Time project, now in maintenance mode, advises migration to the java.time classes.
To learn more, see the Oracle Tutorial. And search Stack Overflow for many examples and explanations. Specification is JSR 310.
You may exchange java.time objects directly with your database. Use a JDBC driver compliant with JDBC 4.2 or later. No need for strings, no need for java.sql.* classes.
Where to obtain the java.time classes?
Java SE 8, Java SE 9, Java SE 10, Java SE 11, and later - Part of the standard Java API with a bundled implementation.
Java 9 adds some minor features and fixes.
Java SE 6 and Java SE 7
Most of the java.time functionality is back-ported to Java 6 & 7 in ThreeTen-Backport.
Android
Later versions of Android bundle implementations of the java.time classes.
For earlier Android (<26), the ThreeTenABP project adapts ThreeTen-Backport (mentioned above). See How to use ThreeTenABP….
The ThreeTen-Extra project extends java.time with additional classes. This project is a proving ground for possible future additions to java.time. You may find some useful classes here such as Interval, YearWeek, YearQuarter, and more.
I want to convert string date to Cassandra time stamp format
Example date
String inputDate="20170525"
You need to convert your string to Date.
Java Date type maps cassandra timestamp type
DateFormat dateFormat = new SimpleDateFormat("yyyyMMdd");
Date date = dateFormat.parse("20170525");
Now you have the date you can insert or query with it in prepared statement
Note : You don't have any timezone. So default timezone will be used. If you want to specify the timezone use dateFormat.setTimeZone(TimeZone zone) method
First, parse that input string as a LocalDate.
LocalDate ld = LocalDate.parse( "20170525" , DateTimeFormatter.BASIC_ISO_DATE ) ;
For a date-only value without time-of-day, you should be using type Date in Cassandra according to this documentation.
You can exchange data as strings using standard ISO 8601 format. The java.time classes use the standard formats by default. So no need to specify a formatting pattern.
String output = ld.toString() ;
2017-05-25
If you really want to store in the timestamp, you must specify a time-of-day. Perhaps you want the first moment of the day. Determining that specific moment on the timeline that requires a time zone. Do not assume the first moment occurs at 00:00:00. Anomalies such as Daylight Saving Time mean the time may be another value such as 01:00:00.
ZoneId z = ZoneId.of( "America/Montreal" ) ;
ZonedDateTime zdt = ld.atStartOfDay( z ) ;
zdt.toString(): 2017-05-25T00:00:00-04:00[America/Montreal]
Cassandra stores the Timestamp field only as UTC. So we need to adjust the ZonedDateTime from our desired time zone to UTC. The easiest way to do that is extract a Instant. The Instant class is always in UTC by definition.
Instant instant = zdt.toInstant() ;
Generate a string in standard ISO 8601 format for Cassandra. Notice how the hour jumps from zero to four. Our time zone America/Montreal is four hours behind UTC on that date. So getting to UTC means adding four hours, 0 + 4 = 4.
String output = instant.toString() ;
2017-05-25T04:00:00Z
Going the other way when your retrieve this value.
Instant instant = Instant.parse( "2017-05-25T04:00:00Z" ) ;
ZonedDateTime zdt = instant.atZone( z );
About java.time
The java.time framework is built into Java 8 and later. These classes supplant the troublesome old legacy date-time classes such as java.util.Date, Calendar, & SimpleDateFormat.
The Joda-Time project, now in maintenance mode, advises migration to the java.time classes.
To learn more, see the Oracle Tutorial. And search Stack Overflow for many examples and explanations. Specification is JSR 310.
Where to obtain the java.time classes?
Java SE 8, Java SE 9, and later
Built-in.
Part of the standard Java API with a bundled implementation.
Java 9 adds some minor features and fixes.
Java SE 6 and Java SE 7
Much of the java.time functionality is back-ported to Java 6 & 7 in ThreeTen-Backport.
Android
The ThreeTenABP project adapts ThreeTen-Backport (mentioned above) for Android specifically.
See How to use ThreeTenABP….
The ThreeTen-Extra project extends java.time with additional classes. This project is a proving ground for possible future additions to java.time. You may find some useful classes here such as Interval, YearWeek, YearQuarter, and more.
My class has 2 properties that make up its date:
java.util.Date date;
String timeZone;
How can I see if this date is before the current time on the server?
Basically I want to write something like this, but take timeZone into account:
return date.before(new Date());
Date stores internally as UTC, so your timeZone variable is not necessary. You can simply use Date.before(Date).
Calendar startCalendar = Calendar.getInstance();
int startTimeZoneOffset = TimeZone.getTimeZone(timeZone).getOffset(startDate.getTime()) / 1000 / 60;
startCalendar.setTime(startDate);
startCalendar.add(Calendar.MINUTE, startTimeZoneOffset);
Calendar nowCalendar = Calendar.getInstance();
int nowTimeZoneOffset = nowCalendar.getTimeZone().getOffset(new Date().getTime()) / 1000 / 60;
nowCalendar.setTime(new Date());
nowCalendar.add(Calendar.MINUTE, nowTimeZoneOffset);
return startCalendar.before(nowCalendar);
tl;dr
Use Instant class, which is always in UTC. So time zone becomes a non-issue.
someInstant.isBefore( Instant.now() )
java.time
The modern approach uses the java.time classes that supplanted the terrible Date & Calendar classes.
As the correct Answer by Kuo stated, your java.util.Date is recording a moment in UTC. So no need for a time zone.
Likewise, its replacement, the java.time.Instant class, also records a moment in UTC. So no time zone needed.
Instant instant = Instant.now() ; // Capture current in UTC.
So all you need as member variables on your class is Instant.
public class Event {
Instant when ;
…
}
To compare Instant objects, use the isAfter, isBefore, and equals methods.
someInstant.isBefore( Instant.now() )
For presentation in a time zone expected by the user, assign a ZoneId to get a ZonedDateTime object. The Instant and the ZonedDateTime both represent the same moment, the same point on the timeline, but viewed through different wall-clock time.
ZoneId z = ZoneId.of( "America/Montreal" ) ;
ZonedDateTime zdt = instant.atZone( z ) ; // Same moment, different wall-clock time.
String output = zdt.toString() ; // Generate text in standard ISO 8601 format, wisely extended to append the name of the zone in square brackets.
Or let java.time automatically localize output. To localize, specify:
FormatStyle to determine how long or abbreviated should the string be.
Locale to determine:
The human language for translation of name of day, name of month, and such.
The cultural norms deciding issues of abbreviation, capitalization, punctuation, separators, and such.
Example:
Locale l = Locale.CANADA_FRENCH ; // Or Locale.US, Locale.JAPAN, etc.
DateTimeFormatter f = DateTimeFormatter.ofLocalizedDateTime( FormatStyle.FULL )
.withLocale( l );
String output = zdt.format( f );
About java.time
The java.time framework is built into Java 8 and later. These classes supplant the troublesome old legacy date-time classes such as java.util.Date, Calendar, & SimpleDateFormat.
The Joda-Time project, now in maintenance mode, advises migration to the java.time classes.
To learn more, see the Oracle Tutorial. And search Stack Overflow for many examples and explanations. Specification is JSR 310.
You may exchange java.time objects directly with your database. Use a JDBC driver compliant with JDBC 4.2 or later. No need for strings, no need for java.sql.* classes.
Where to obtain the java.time classes?
Java SE 8, Java SE 9, Java SE 10, Java SE 11, and later - Part of the standard Java API with a bundled implementation.
Java 9 adds some minor features and fixes.
Java SE 6 and Java SE 7
Most of the java.time functionality is back-ported to Java 6 & 7 in ThreeTen-Backport.
Android
Later versions of Android bundle implementations of the java.time classes.
For earlier Android (<26), the ThreeTenABP project adapts ThreeTen-Backport (mentioned above). See How to use ThreeTenABP….
The ThreeTen-Extra project extends java.time with additional classes. This project is a proving ground for possible future additions to java.time. You may find some useful classes here such as Interval, YearWeek, YearQuarter, and more.