System Date Friday, 14 Sep 2007
System Time 16:56:28
System Favourite Colour Periwinkle
Java Version 1.5.0
Java Vendor IBM Corporation
JVM Version 1.0
JVM Vendor Sun Microsystems Inc.
JVM Implementation Version 2.3
Java Runtime Java(TM) 2 Runtime Environment, Standard Edition
Java VM IBM J9 VM
User Name ewikiap1
User Timezone America/New_York
Operating System Linux 2.6.9-22.0.2.ELsmp
OS Architecture x86
Filesystem Encoding ANSI_X3.4-1968
System Date Friday, 14 Sep 2007
System Time 16:56:28
System Favourite Colour Periwinkle
Java Version 1.5.0
Java Vendor IBM Corporation
JVM Version 1.0
JVM Vendor Sun Microsystems Inc.
JVM Implementation Version 2.3
Java Runtime Java(TM) 2 Runtime Environment, Standard Edition
Java VM IBM J9 VM
User Name ewikiap1
User Timezone America/New_York
Operating System Linux 2.6.9-22.0.2.ELsmp
OS Architecture x86
Filesystem Encoding ANSI_X3.4-1968
The latest releast 2.3-dr7 displays time incorrectly when using the {date-data} macro in this format:
{date-data:x|format=hh:mma}{date-data}.
In edit mode, if you set the time to 02:03 AM, in view/preview mode it shows 01:59 am.
Have attached screenshots.
Description
The latest releast 2.3-dr7 displays time incorrectly when using the {date-data} macro in this format:
{date-data:x|format=hh:mma}{date-data}.
In edit mode, if you set the time to 02:03 AM, in view/preview mode it shows 01:59 am.
Have attached screenshots.
Confirmed this issue. The time it would actually set was somewhat arbitrary - on some computers it was forward, on some, backwards.
The problem was that when no year value was being supplied, the year '0' (which technically, does not even exist) was being used instead. This was compiling, but was introducing the noted error.
Choosing which year is appropriate for non-specified values is a little tricky, but 2000 was decided on. It is recent enough to be reliable, is a nice round number, and will be consistent. An alternative considered was the current year, but this would cause problems when sorting by the date, since newer values may be set to a different year, which would alter the sort order when it is intended to sort by the time.
David Peterson - 10/Oct/07 07:42 AM Confirmed this issue. The time it would actually set was somewhat arbitrary - on some computers it was forward, on some, backwards.
The problem was that when no year value was being supplied, the year '0' (which technically, does not even exist) was being used instead. This was compiling, but was introducing the noted error.
Choosing which year is appropriate for non-specified values is a little tricky, but 2000 was decided on. It is recent enough to be reliable, is a nice round number, and will be consistent. An alternative considered was the current year, but this would cause problems when sorting by the date, since newer values may be set to a different year, which would alter the sort order when it is intended to sort by the time.
Bug
Resolved
Major
New scaffolding version 2.3-dr7 displaying time incorrectly
The problem was that when no year value was being supplied, the year '0' (which technically, does not even exist) was being used instead. This was compiling, but was introducing the noted error.
Choosing which year is appropriate for non-specified values is a little tricky, but 2000 was decided on. It is recent enough to be reliable, is a nice round number, and will be consistent. An alternative considered was the current year, but this would cause problems when sorting by the date, since newer values may be set to a different year, which would alter the sort order when it is intended to sort by the time.