Closed Bug 366921 Opened 18 years ago Closed 3 years ago

problem with importing exported event (csv)

Categories

(Calendar :: Import and Export, defect)

defect
Not set
major

Tracking

(Not tracked)

RESOLVED WONTFIX

People

(Reporter: damian.publicemail, Unassigned)

References

Details

Attachments

(1 file)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; pl; rv:1.8.1.1) Gecko/20061204 Firefox/2.0.0.1
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a2pre) Gecko/20070112 Calendar/0.4a1

I can not import exported event - get error and some values are set to null

Reproducible: Always

Steps to Reproduce:
1. create clean profile
2. create simply event
3. export calendas as csv
4. delete created event
5. import exported calendar (single event)

Actual Results:  
error console:

Error: [Exception... "Component returned failure code: 0x80070057 (NS_ERROR_ILLEGAL_VALUE) [nsIScriptableDateFormat.FormatDate]"  nsresult: "0x80070057 (NS_ERROR_ILLEGAL_VALUE)"  location: "JS frame :: file:///C:/Sunbird/js/calDateTimeFormatter.js :: formatDateLong :: line 149"  data: no]
Source File: file:///C:/Sunbird/js/calDateTimeFormatter.js
Line: 149


see at the event in unifinder:
category = null
start and date is empty
I can confirm using Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8.1.3pre) Gecko/20070317 Calendar/0.5pre.

During CSV import no error dialog or error message in console is shown.

The error message mentioned in previous comment is generated each time the unifinder tries to format the empty Start and End date for display purpose.
OS: Windows XP → Windows 2000
Version: unspecified → Trunk
Actually the problem seems to be our CSV export. An exported event looks like

"Test","03/17/07","10:00:00 ","03/17/07","12:00:00 ", ...

If I manually change that line to

"Test","03/17/07","10:00:00 AM","03/17/07","12:00:00 PM",

the CSV import also works fine. Depends on Bug 359083.
Depends on: 359083
After adjusting my Windows system as described in Bug 359083 Comment #2 the CSV export doesn't loose AM/PM information. The CSV import afterwards now correctly recognizes the date and time. In the unifinder the start and end date is correctly shown as 17-March-2007.

But in the calendar views the event is displayed on 17-March-0007 - two thousands year before the correct date...
The cvs-export has following issues:
 - The start/end times have missing AM/PM (bug 359083)
 - The start/end dates use two digits instead of 4 (see comment #3 above)
 - The alarm on/off and alarm date/time is missing - just an empty string ("")
Related to Sunbird 0.3.1: 
The cvs-import function has following issues:
 - It dus not import the alarm settings (Reminder fields)
 - It requires a significant value for the "Reminder date" field,
      even if the "Reminder on/off" value = "False"
 - Suppress duplicate events is very desirable:
      I use a PDA - to synchronise I (must) use Active-sync and Outlook
      to get the calender info to my PC. Then I export the Outlook agenda
      into a cvs-file. This can be imported in Sunbird, but all already
      imported events get imported again, so duplicates arise.
      An option to skip already imported events is very desirable.

      Ofcourse a method to sync the PDA directly with Sunbird would be far
      more superior: Then I could transfer events also from PC tot PDA...
Flags: blocking-calendar0.5-
Leo, see http://wiki.mozilla.org/Calendar:For_Everyone:Blocking_Flags for the appropriate use of blocking flags.
Flags: blocking-calendar0.5-
Concerning the Blocking Flag:
- The cvs-file import from Outlook works OK 
- The request for an import-feature to avoid doubles will only be usefull
    for a small number of people
- Other exports/imports can not be an issue to delay release 0.5
Therefore the blocking flag should remain blank (as I understood it)

(Besides the sync-issue with PDA, this program feels better than MS Outlook!)
I notice on my 0.7 version of Lightning, that when I export to CSV file, the dates are "01/01/08" NOT "01/01/2008".  When I import the original exported file, then the events are stored as 01/01/0008 (evidenced by a subsequent export).

If I take a clean (unmodified) exported file and change the dates to include the century, then the import works fine.

I also notice that if I read this exported file into EXCELL and, without modification, simply save it out as a CSV file, then all of the quotes are removed from the data.... (a CSV file only quotes data that contain a comma), and the CSV file is unable to be imported... (It appears to work, but the data is not imported at all).

I would be glad to work on this problem, but I do not have a mozilla development environment set up...

Please try a replacement for the file calOutlookCSVImportExport.js s shown in bug 359083 
I am not familiar with how to use the replacement file, but I tried this:

I cut the source from bug 359083 and backed up my calOutlookCSVImportExport.js file on my local C: drive.  Then I created a new file called calOutlookCSVImportExport.js and pasted the code in there.

I then tried the CSV export of a calendar, checked the output and the dates still are formatted with just the year, not the century... i.e. 01/01/2008 was 01/01/08

I then created a new calendar and imported this file back in to the new calendar without making any manual changes to the .csv file.  The dates came back in as, i.e.  01/19/'.  (should be 01/19/2008).  Since the dates were not correct, then the calendar did not display the proper output.

1) Did I do the right thing to test the new code?
2) Is it possible that I have a date configuration setting wrong?

Thanks

Mark
> I cut the source ... I then tried the CSV export of a calendar, ...

Thanks for testing. Please send me your calOutlookCSVImportExport.js and the generated output file. 

> checked the output and the dates still are formatted with just the year, 
> not the century... i.e. 01/01/2008 was 01/01/08

Responsible for formating the date output in Sunbird is line 88 in the original file. The format codes follow strftime syntax Uppercase %Y should give YYYY. 
I changed        dateFormat : "%m/%d/%y",
to               dateFormat : "%m/%d/%Y",

> 1) Did I do the right thing to test the new code?

Probably yes. You could have downloaded file https://bugzilla.mozilla.org/attachment.cgi?id=297296 directly

> 2) Is it possible that I have a date configuration setting wrong?

I don't think so. I'm going to test this on lightning.
I tested on Thunderbird DE Version 2.0.0.9 (20071031) with Lightning 0.7 after downloading file 297296 to the profiles folder. It worked.

A second version is now available. See bug 359083 comment 14 with the description of the folders where this file has to be placed.
Note to maintainers/ssitter: This bug depends not on bug 359083. Please delete the dependency.
I have also confirmed that the problem is resolved.
Status: NEW → ASSIGNED
No longer depends on: 359083
Assignee: nobody → hb
Status: ASSIGNED → NEW
Version: Trunk → unspecified
Status: NEW → ASSIGNED
Part of the general solution in bug 359083

Sets default output to four digit years and 24-hours time format.
Attachment #307524 - Flags: review?(mvl)
Comment on attachment 307524 [details] [diff] [review]
Patch Default output now MM/DD/YYYY and 24 hrs time

This was small an intermediate solution which didn't make it into 0.8. 

For 0.9 we should take the big one in bug 359083.
Attachment #307524 - Attachment is obsolete: true
Attachment #307524 - Flags: review?(mvl)
Attachment #307524 - Attachment is obsolete: false
Attachment #307524 - Flags: review?(mvl)
Hb, since we are past 0.8 now, should we mark this bug as a duplicate of bug 359083?
Depends on: 359083
Attachment #307524 - Flags: review?(mvl)
Assignee: hb → nobody
Status: ASSIGNED → NEW
Assignee: nobody → anidps
OS: Windows 2000 → All
Hardware: x86 → All
Assignee: anidps → nobody
Blocks: 982133

The import/export code for Outlook CSV format has been removed in bug 1226851. Therefore resolving this bug report as WONTFIX.

Status: NEW → RESOLVED
Closed: 3 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: