You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ofbiz.apache.org by Visvendra Singh Rajpoot <vi...@outlook.com> on 2016/01/23 11:34:03 UTC
Standard Date Format across application
Hello,
Although it has been in discussion under various threads let's give it another chance to close.
We noticed the following concerns before we get into making standard date format across application-Java or GroovyTimestamp.valueOf : it takes only yyyy-[m]m-[d]d hh:mm:ss[.f...]Using formatter = new SimpleDateFormat("yyyy-MM-dd HH:mm:ss.S") with different formatUtilDateTime.java datetime, date and time format is not configurable.toString() on Date and Timestamp being used which always returns yyyy-mm-dd hh:mm:ss.fffffffff format.FTL/XML ?string() being usedtoString also being usedgetString() being used on GenericValuesformatDateTime() method of UtilFormatOut.java
To make date format standard we did-Made UtilDateTime.java datetime, date and time formats configurable (through properties file).Set datetime_format, time_format and date_format patterns at free marker configuration level.Changed all hard coded format patterns from UtilDateTime configured patterns.Removed following from ftls?string() [ To remove all hard coded patterns of rendering] toString() getString() to get timestamp valueAdded patterns (not hard coded) to all formatDateTime() method of UtilFormatOut.java
Total number of files being affected is approximate 62 and total number of changes is approx 1k.
Do anyone see any concern that is not considered?
Regards,-Visvendra Singh
RE: Standard Date Format across application
Posted by Visvendra Singh Rajpoot <vi...@outlook.com>.
Hello,
Although it has been in discussion under various threads let's give it another chance to close.
We noticed the following concerns before we get into making standard date format across application-
Java or Groovy
- Timestamp.valueOf : it takes only yyyy-[m]m-[d]d hh:mm:ss[.f...]
- Using formatter = new SimpleDateFormat("yyyy-MM-dd HH:mm:ss.S") with different format
- UtilDateTime.java datetime, date and time format is not configurable.
- toString() on Date and Timestamp being used which always returns yyyy-mm-dd hh:mm:ss.fffffffff format.
FTL/XML
- ?string() being used
- toString also being used
- getString() being used on GenericValues
- formatDateTime() method of UtilFormatOut.java
To make date format standard we did-
- Made UtilDateTime.java datetime, date and time formats configurable (through properties file).
- Set datetime_format, time_format and date_format patterns at free marker configuration level.
- Changed all hard coded format patterns from UtilDateTime configured patterns.
- Removed following from ftls
- ?string() [ To remove all hard coded patterns of rendering]
- toString()
- getString() to get timestamp value
- Added patterns (not hard coded) to all formatDateTime() method of UtilFormatOut.java
Total number of files being affected is approximate 62 and total number of changes is approx 1k.
Do anyone see any concern that is not considered?
Regards,
-Visvendra Singh
> From: visvendra@outlook.com
> To: dev@ofbiz.apache.org; user@ofbiz.apache.org
> Subject: Standard Date Format across application
> Date: Sat, 23 Jan 2016 10:34:03 +0000
>
>
>
>
> Hello,
> Although it has been in discussion under various threads let's give it another chance to close.
> We noticed the following concerns before we get into making standard date format across application-Java or GroovyTimestamp.valueOf : it takes only yyyy-[m]m-[d]d hh:mm:ss[.f...]Using formatter = new SimpleDateFormat("yyyy-MM-dd HH:mm:ss.S") with different formatUtilDateTime.java datetime, date and time format is not configurable.toString() on Date and Timestamp being used which always returns yyyy-mm-dd hh:mm:ss.fffffffff format.FTL/XML ?string() being usedtoString also being usedgetString() being used on GenericValuesformatDateTime() method of UtilFormatOut.java
> To make date format standard we did-Made UtilDateTime.java datetime, date and time formats configurable (through properties file).Set datetime_format, time_format and date_format patterns at free marker configuration level.Changed all hard coded format patterns from UtilDateTime configured patterns.Removed following from ftls?string() [ To remove all hard coded patterns of rendering] toString() getString() to get timestamp valueAdded patterns (not hard coded) to all formatDateTime() method of UtilFormatOut.java
> Total number of files being affected is approximate 62 and total number of changes is approx 1k.
> Do anyone see any concern that is not considered?
>
> Regards,-Visvendra Singh
>
FW: Standard Date Format across application
Posted by Visvendra Singh Rajpoot <vi...@outlook.com>.
Formatting was removed earlier.
From: visvendra@outlook.com
To: dev@ofbiz.apache.org; user@ofbiz.apache.org
Subject: Standard Date Format across application
Date: Sat, 23 Jan 2016 10:34:03 +0000
Hello,
Although it has been in discussion under various threads let's give it another chance to close.
We noticed the following concerns before we get into making standard date format across application-Java or GroovyTimestamp.valueOf : it takes only yyyy-[m]m-[d]d hh:mm:ss[.f...]Using formatter = new SimpleDateFormat("yyyy-MM-dd HH:mm:ss.S") with different formatUtilDateTime.java datetime, date and time format is not configurable.toString() on Date and Timestamp being used which always returns yyyy-mm-dd hh:mm:ss.fffffffff format.FTL/XML ?string() being usedtoString also being usedgetString() being used on GenericValuesformatDateTime() method of UtilFormatOut.java
To make date format standard we did-Made UtilDateTime.java datetime, date and time formats configurable (through properties file).Set datetime_format, time_format and date_format patterns at free marker configuration level.Changed all hard coded format patterns from UtilDateTime configured patterns.Removed following from ftls?string() [ To remove all hard coded patterns of rendering] toString() getString() to get timestamp valueAdded patterns (not hard coded) to all formatDateTime() method of UtilFormatOut.java
Total number of files being affected is approximate 62 and total number of changes is approx 1k.
Do anyone see any concern that is not considered?
Regards,-Visvendra Singh