Author Topic: Version 6 File Naming Using Date  (Read 2943 times)

Offline pbmike

  • Newcomer
  • *
  • Posts: 5
    • View Profile
Version 6 File Naming Using Date
« on: April 04, 2019, 03:37:07 PM »
I am running v6.0 build 2725 on Windows 10.  When ingesting using "{mdts}-Filename-{seqn}", my files changed date at 8PM.  From the XMP:

    xmp:CreateDate="2019-04-03T20:00:23.12-04:00"

The file started with "20190404".  The previous file started with "20190403".  All photos were taken on 4/3.

This is a minor issue, but should be fixed in a future version.

Thanks, Mike Peterson

Offline dennis

  • President
  • Camera Bits Staff
  • Sr. Member
  • *****
  • Posts: 461
    • View Profile
    • Camera Bits, Inc.
Re: Version 6 File Naming Using Date
« Reply #1 on: April 04, 2019, 04:39:08 PM »
Mike,

You are using the modification date variable.  Why?  I assume you processed photos taken on 4/3 on 4/4?

--dennis

Offline pbmike

  • Newcomer
  • *
  • Posts: 5
    • View Profile
Re: Version 6 File Naming Using Date
« Reply #2 on: April 04, 2019, 07:25:24 PM »
Everything was processed on 4/3

Offline pbmike

  • Newcomer
  • *
  • Posts: 5
    • View Profile
Re: Version 6 File Naming Using Date
« Reply #3 on: April 04, 2019, 07:45:43 PM »
Using {dats} gives the correct YYYYMMDD.  {mdts} still changes at 8PM.  Files process on 4/4 (just now):  everything captured prior to 8PM is 20190403, and everything after 8PM is 20190404.  I've been using {mdts} since I started using PhotoMechanic, which is October of 2016, and I've never had an issue.  I'll change to {dats}, but it still begs the question because the files have the same creation and modification date/time.  The files are from my backup device (a Nextodi ND2901) that makes a copy of my memory card.  It has no internal clock so it doesn't set any date/time.

Offline Kirk Baker

  • Senior Software Engineer
  • Camera Bits Staff
  • Superhero Member
  • *****
  • Posts: 24681
    • View Profile
    • Camera Bits, Inc.
Re: Version 6 File Naming Using Date
« Reply #4 on: April 04, 2019, 08:46:20 PM »
Mike,

Using {dats} gives the correct YYYYMMDD.  {mdts} still changes at 8PM.  Files process on 4/4 (just now):  everything captured prior to 8PM is 20190403, and everything after 8PM is 20190404.  I've been using {mdts} since I started using PhotoMechanic, which is October of 2016, and I've never had an issue.  I'll change to {dats}, but it still begs the question because the files have the same creation and modification date/time.  The files are from my backup device (a Nextodi ND2901) that makes a copy of my memory card.  It has no internal clock so it doesn't set any date/time.

What is the modification time of one of the files that produces this problem?

-Kirk

Offline pbmike

  • Newcomer
  • *
  • Posts: 5
    • View Profile
Re: Version 6 File Naming Using Date
« Reply #5 on: April 05, 2019, 05:16:24 AM »
I've attached the properties of the first file that shows the problem.

Offline Kirk Baker

  • Senior Software Engineer
  • Camera Bits Staff
  • Superhero Member
  • *****
  • Posts: 24681
    • View Profile
    • Camera Bits, Inc.
Re: Version 6 File Naming Using Date
« Reply #6 on: April 05, 2019, 06:45:02 AM »
If you use {mdts} in your Info Text (Edit->Settings->Set Info Text...) what does PM6 show for that item when you view it in the Preview window and look at the Info Text pane on the right side of the Preview window?

-Kirk

Offline pbmike

  • Newcomer
  • *
  • Posts: 5
    • View Profile
Re: Version 6 File Naming Using Date
« Reply #7 on: April 05, 2019, 10:17:04 AM »
Info Text Settings:

    ModDate: {moddatesort}
    Date: {date}
    Time: {time}

Info Text Results:

    ModDate: 20190404
    Date: 4/3/2019
    Time: 8:00:23 PM

Offline dennis

  • President
  • Camera Bits Staff
  • Sr. Member
  • *****
  • Posts: 461
    • View Profile
    • Camera Bits, Inc.
Re: Version 6 File Naming Using Date
« Reply #8 on: April 05, 2019, 01:40:03 PM »
Well it seems like if you use Capture time variable then all should be well.

It looks like in PM 6 (for synchronization reasons), we convert to GMT time which apparently is 4 hours ahead of you (e.g. if you are on US East coast).

I am fixing the variables for modification time to convert back to local time for display purposes so you can wait for that update or use {dats} instead.

--dennis